Aggregation upstream projects are BAD (kdesdk for example)

[Kevin Kofler]

Michel Salim <michel.sylvan <at> gmail.com> writes:
> Ditto, though in this case, umbrello happens to *also* be part of kdesdk:
> 
> http://uml.sourceforge.net/download.php
> 
> The source tarballs are taken straight out of kdesdk CVS, so the
> Fedora packaging, while needing to be fixed, is understandable.

Well, as you're saying, kdesdk here is the canonical source, the separate 
tarballs are taken out of kdesdk SVN, and it is also included in kdesdk, so 
packaging Umbrello as part of kdesdk fully makes sense.

As for Hans de Goede's worry: a KDE 3.5.8 bugfix release is planned. Given that 
the latest Umbrello comes straight out of the KDE 3.5 SVN branch, it will also 
end up in there.

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

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

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.

        Kevin Kofler