splitting up distro packages (was: KDE 4 modules structure (again))

[Dominique Devriese]

Maks Orlovich writes:

>> I would argue that their benefits outweigh their disadvantages
>> though.

> Eh, the most significant benefit is for cases of security upgrades,
> where less data has to be downloaded. This is compelling, but if
> more subcomponents are affected, this means there are more packages
> to upgrade, too, and there are other solutions --- i.e. SuSE IIRC
> does patch RPMs.

> And please, no nonsense about "saving disk space". Saving a few
> hundred kilobytes these days is silly. (And people who are short on
> disk space probably should not trade quite so many MP3s).

1 Knoppix and related cd's are very concerned with disk space.
2 Debian policy disallows not splitting the packages
3 A lot of admin's are still very concerned with disk space.
4 There are no downsides, if you provide proper metapackages.

It is simply good packaging practice to properly split up the
packages, and if some distributions don't do it atm, then that is
simply due to the amount of effort it would take.  Look at gnome,
which is properly split up in every distro I know.

>> > 4. Many applications are too small to be in separate modules. KCalc?
>> >    KFloppy? come on!
>>
>> Any particular reason why not ?  

> Ehh, good luck managing installations then. Each package = separate
> entry to keep track of, to install/uninstall/upgrade. If it's
> something like kmail, well, that's OK. If it something like kcalc or
> ktimer, it's just a lot of extra work.

This can be automated.

>> > 6. Discourages developers from contributing to multiple
>> >    applications/diminishes the community aspect of modules.
>>
>> I don't think this is true.  Developers ignore the current
>> module-boundaries at the moment as well.

> They do? Hmm, wonder about kdepim-devel, kdegraphics-devel, etc.?

If you want to give these sorts of examples, then look at
lists.kde.org and compare the number of app-specific
vs. module-specific lists.

cheers
domi