Michael Scherer wrote: > Given the target of rawhide, I expect people to be able to clean the > unneeded packages after a while. Heck, like they do for packages that > got orphaned and removed. My concern is not Rawhide, my concern is stable releases, especially if one upgrades from one release of Fedora to the next, then to the next etc. Fedora installations usually go through many upgrades, seeing how we release every 6 months. The problem with your proposal is that it is focused on Rawhide and ignores the impact on our actual releases. > And do you have any number ? Cause I have been running distro with such > policy and "many MiB" still doesn't make much to my experience, so > provides credible numbers if you wish to make your point , especially > when talking to people who have seen this policy in action. Let's just take one of the few compatibility stacks we actually have to carry (because porting is far from trivial) as an example: Name : qt3 Version : 3.3.8b Release : 41.fc17 Architecture: i686 Size : 10467741 Name : kdelibs3 Version : 3.5.10 Release : 42.fc17 Architecture: i686 Size : 38669698 Name : kdebase3 Version : 3.5.10 Release : 20.fc17 Architecture: i686 Size : 17612161 Name : kdebase3-libs Version : 3.5.10 Release : 20.fc17 Architecture: i686 Size : 1317496 Now multiply this by the number of soname bumps in the lifetime of an installation (just look at how often there are broken dependencies from a soname bump in the Rawhide reports) and see for yourself what doing the math leaves you with. And in addition to the space issue, the old libraries would also be unmaintained and not get any security fixes. Maintaining all the old libraries with old sonames we ever releases just does not scale! See e.g. how upgrading to a new version for security reasons is explicitly listed as an exception to the policy of not bumping sonames in updates for stable releases in https://fedoraproject.org/wiki/Updates_Policy . It's all the more valid for Rawhide / between different releases (because each individual release goes EOL after ~13 months, Rawhide never goes EOL, nor does Fedora as a whole of course, so old stuff can get REALLY old). Leaving old unmaintained libraries lying around on user systems is a security disaster! > I do not see how it would feel wrong to try to fix a issue by changing a > policy. And I do not see why Rawhide should be less important than > stable for that matter. Because the whole purpose of Rawhide is to serve as a development bed for our stable releases. Rawhide is not and should not be our product, our releases are. And in any cases, the releases do exist and you cannot entirely ignore their existence in your proposal. > Usually, you have 3 months for branched to make sure everything is > rebuild and that there is only 1 version of a lib. Have you read what > Olav said, about "packages without source rpm will be removed after 2 > weeks", and "then they show as having "broken deps in report" ? Removing the old packages is not enough, you actually have to add Obsoletes to the current version if you don't want the old versions to accumulate on upgrades from one stable release to the next. And who is going to enforce the Obsoletes? It WILL get forgotten more often than not. We already have enough broken upgrade paths as it stands. In addition, having those Obsoletes will make users complain "Why does yum want to remove the compatibility library my [broken, not recompiled against the current Fedora] third-party package needs?", whereas not having them will make old (and unmaintained!) versions accumulate (as I said before). The best way to avoid such confusion is to avoid setting false expectations in the first place by just not version-suffixing the libraries. > Not to mention that having the old version for a few days doesn't mean > people cannot go ahead and rebuild their packages as they do now, the > only difference is for users, since this permit to have a installable > rawhide for a more longer period of time. Just to avoid a window of a few days, your proposal wants to introduce a version suffix we're stuck with forever. This seems very wrong. > yum history undo work fine for simple and medium cases, but after a > while due to the level of churn on stable release, it can break : > http://pastebin.com/Bdt6ngy2 The use case I was talking about is, you try the package, you don't like it, you uninstall it (before doing any other yum operations). Indeed, undoing an older yum operation may or may not work. But it's not the common case: Why would you want to uninstall a package after deciding you like it? > That's just package naming. If you are more concerned by the name of the > rpm than by having users, there is priority issue. We have users right now, without your proposal. And naming is an important issue: If you buy beef lasagne, you don't want to have horse meat in them! Likewise, if you install kdelibs4, you don't want to get kdelibs 3 installed. > That's still not explaining. 2 is not "several". With the security issue, I listed 3 reasons now. :-) There are certainly more, but those 3 are already severe enough to make your proposal a complete no go. > And "I do not accept solution" is not the same as "there is no solution". It's not that *I* don't accept your "solution", it's just that it doesn't work. Kevin Kofler -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
