Aggregation upstream projects are BAD (kdesdk for example)

[Michel Salim]

On 11/09/2007, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Michel Salim <michel.sylvan <at> gmail.com> writes:
> Both monolithic and modular packaging has advantages and disadvantages. The
> advantages of the monolithic way:
> * less packages => less packaging work
> * clearer versioning: You know that you're using KDE 3.5.7, whereas for e.g.
> GNOME, you have stuff versioned 2.18.0, 2.18.1, 2.18.2, ... and it's hard to
> figure out what GNOME version this actually corresponds to (and similarly for
> the new modular X.Org X11).
>
Oh yes. Figuring out which parts of X.org 7.3 is in F8 and which is
not, is not exactly trivial.

> But of course, the advantages of the modular way (independent updates, better
> granularity for end-users) have been beaten to death on this list already. The
> granularity could be obtained in other ways though (e.g. subpackages).
>
Subpackages give end-users better granularity, but still does not
allow for independent updates (unless, taking Umbrello as an example,
an urgent Umbrello release is handled by building a separate package
that is versioned higher than the bundled kdesdk-umbrello). Gets
unwieldy really fast!

(Alternatively, kdesdk maintainer needs to pull the fix pertaining to
Umbrello, apply it as a patch, release it and prepare for the grumbles
from other kdesdk users who then have to upgrade)

> Still, my current position (and as far as I was able to tell from the general
> feeling when this issue came up in the IRC meetings, also the one of the KDE
> SIG, feel free to correct me if I'm misrepresenting anyone's opinion here) is
> that unleashing even a subpackage for every single KDE app would lead to a
> gigantic mess which would cause more problems than it solves.
>
Seems reasonable.

Regards,

-- 
Michel