KDE 4 modules structure (again)

[Maks Orlovich]

> > That's only an advantage if you don't consider splitting of packages
> > to be a very bad idea, which in my experience as a Mandrake (which
> > first had monolythic packages, and then split them) user, it is, due
> > to much-much harder maintenance and administration (plus the
> > tendency of packagers to split stuff that really has 0 advantage of
> > being split).  At any rate, this is not an undisputably good thing
> > at all.
>
> 1 I am not talking about your life as a sysadmin, but packagers'
>   lives.

Eh, if I believe splitting packages is a bad idea, and packagers do it anyway, 
then, well, they're creating more work for themselves (and likely more 
packaging problems) for no good reason. I don't see why that should be a 
concern. 

>
> 2 The advantages of split distribution packages is an orthogonal
>   discussion, as packages are split by the packagers at the moment. 

No, it's not, since split source modules make large modules more work, not 
less work. And as for they are split already --- well, not by everyone, and 
to very different extents. For KDE3.2.1,looking through download.kde.org (for 
only arch-specific modules, not the i18n ones), which admittedly sometimes 
includes things not strictly in KDE, but which is a good estimate, I see the 
following stats:
ASPLinux:  37 packages
Slackware: 46
Fedora:    49 (but it also includes PyQt and such). 
SuSE:      92 with split apparently by large groupings, or dependency related.

For 3.2, we also see:
Connectiva: 449

From their mirror:
Mandrake: ~160

Anyone know how many packages Debian has?


Some of these are reasonable decisions. Some aren't. And of course, that 
people already do it, doesn't mean it's smart. Please, argue on merits, not 
by treating us like lemmings. 

>   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). 


>
> >> Possible disadvantages are: 1 More work for developers, but imho,
> >> with a nice set of build scripts, this can be mitigated.  2 It
> >> would require a big move on the CVS server.  Possibly, this can be
> >> combined with the move to SVN that should be coming up some time
> >> soon ?  3 A lot of work is required for doing the move and working
> >> on the build scripts.  True, but a lot of hands make light work.
> >
> > 4. Many applications are too small to be in separate modules. KCalc?
> >    KFloppy? come on!
>
> Any particular reason why not ?  Or why we couldn't aggregate very

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.

> small apps without any special dependencies in small modules again.
> These are things that can be discussed further along in the process.
>
> > 5. Increases the clean build time --- every single module needs to
> >    have configure genederate, configure run; doing this per-module
> >    is quicker than doing this per-application
>
> This is partly true, but its effects are not so bad because:
> 1 The amount of work that configure needs to do per-app will
>   decrease.

Not singnificantly. Most of configure is not app-specific.

> 2 The time taken by configure is small compared to the
>   time taken for building the source.

Not for small apps. And not if you run configure for each of them.


> > 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.?