Guidelines for creating subpackages?

[Denis Leroy]

Yaakov Nemoy wrote:
> On Dec 1, 2007 9:03 PM, Jesse Keating <jkeating at redhat.com> wrote:
>> This is the classic argument.
>>
>> "We need subpackages!"
>>
>> "Why?"
>>
>> "Because it will make Fedora better as a base!"
>>
>> "Why?"
>>
>> "Because it will!"
>>
>> "How?"
>>
>> "Because it will!  If you don't get that, then your dumb!"
> 
> For those "dumb" people, the more granular the packages are, the
> easier it is to pick and choose what you want.  You have more
> "choice".  If the packages are lumps of things, it's very hard to pull
> out what your 1% use case needs and doesn't need.

I feel the most important thing must remain ease of installation for 
end-users. If you "yum install foo", you expect foo to be fully working 
after installation (and how many dependencies it pulls is not 
necessarily important if you're using yum directly). Remember we don't 
really have a mechanism in place to say "since you just installed foo, 
you should really consider installing foo-extras, foo-extensions and 
foo-plugins as well.

And then there's installing from pirut. If I want to install clamav, I 
open up pirut and search for "clamav". I get 17 packages. Which one do I 
have to install to have a sufficient setup ? Splitting packages to make 
dependencies easier to manager is a good idea, but first we may want to 
think about ways to make this less confusing to the end user. When I 
search for clamav, I'd like to see a big red line for the main clamav 
installation line (with all the dependencies it will pull hidden from 
view), and a side panel with a list of optional packages (plugins and 
al) with descriptions. Do we have enough metadata right now to produce 
something like this ?

-denis