Guidelines for creating subpackages?

[Yaakov Nemoy]

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.

For those "smart" people, too much choice is generally a Very Bad
Thing (TM).  As I understand, one goal of the guys doing mkinitrd is
to include bash, a 800k program into the image.  Why? So we don't have
to choose and maintain 15 different shells.

People talk about the 'balkanization' of a platform.  I would call
splitting packages up unecessarily the 'gentooification' of Fedora.
If your 1% user base needs a package done slightly different, then
it's something that IMHO should be done internally.

I might be wrong here, and I would like to hear if there are any
respin ideas or use cases  that aren't for embedded/minimal systems
that would need such ubiquitous fragmentation.

(for non-native english speakers, ubiquitous means all encompassing,
or thorough)

-Yaakov