Aggregation upstream projects are BAD (kdesdk for example)
Hans de Goede
j.w.r.degoede at hhs.nl
Sat Sep 8 13:12:38 UTC 2007
A college of mine wanted to use umbrello in our Universities labs, since the
Linux install there are Fedora he asked me about umbrello for Fedora.
Since I could NOT find it, I packaged it, see:
But then I got a comment to the review it was already in Fedora in kdesdk. But
then why on earth doesn't kdesdk have a Provides umbrello so that yum install
umbrello works? Or even better an umbrello sub-package?
As it currently stands umbrello is just plain unfindable to end users, as you
know I'm not some noob. I even searched for in progress reviews of umbrello.
Also I think it is a very bad idea to ship packages with a clearly seperate
upstream in some kinda bundle form. Sticking with the umbrello example, in
order for the latest version to be included into Fedora, we must wait for a new
upstream kdesdk release, which likely won't happen before there is a kdesdk4 in
some far away future, as kde3 is as good as EOL.
Notice that umbrello and kdesdk are just an example, this goes for other
Aggregation upstreams too.
Since on of Fedora's strenghts is being always up to date with the latest
upstream versions, I think using these kind of upstream aggregation projects is
a BAD idea as it creates interlocks with regards to versions between clearly
seperate projects like kdesdk and umbrello.
If an upstream disolves into something bigger thats a whole different story,
I'm talking about the aggregated project still having a clearly alive and
active upstream. Actually this is much like having apps with bundled other
upstream libs, where we always say these must not be used, and we even delay
reviews, waiting for a package and review of the lib as a seperate package if
necessary. I say we should extend this rule to bundled clearly seperate
More information about the fedora-devel-list