Le lundi 11 mars 2013 à 03:44 +0100, Kevin Kofler a écrit : > Michael Scherer wrote: > > A few wasted mega of disk space do not seems to be big problem if that > > permit to have more people on rawhide, faster tests and faster feedback. > > Old libraries accumulate over the lifetime of an installation, eating many > MiB, not just "a few". 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. 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. > > The priority for rawhide should be having something that work first. > > It feels really wrong to design a whole library packaging policy around > Rawhide. 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. > The focus needs to be on making stable releases clean without > useless legacy compatibility baggage, and Rawhide needs to be the > development bed for that. Compatibility libraries only make sense where the > packages cannot be ported to the new version in time for the release. 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" ? The script is not that hard to do, you can even get the one I wrote from svn ( http://svnweb.mageia.org/adm/puppet/modules/mirror_cleaner/ ). 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. > > And I think the problem could be solved ( and in fact, it is already a > > problem we have for those that install something, then remove the main > > software without cleaning deps ). > > The solution for that problem is called yum history undo, and it doesn't > solve the old library problem. 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 And there is nothing broken on my system according to yum check all. > > We should not refuse the idea on the ground that this is too complex > > for some users to understand the concept of soname. Either they don't, > > and then we should just hide libraries from the UI at some point ( and > > that's already done ), because with or without soname, that will not > > change anything, or they are able to understand and then we should not > > treat them as they couldn't. > > IMHO, having KDE 3 libs versioned as kdelibs4 is totally unacceptable. It's > really confusing. (The only worse way to do things is to append an > unreadable suffix for the C++ ABI to that as Debian did with "kdelibs4c2a". > But if you insist on keeping old ABIs around for any and all ABI changes in > Rawhide, we'll eventually end up with the same mess!) That's just package naming. If you are more concerned by the name of the rpm than by having users, there is priority issue. > > So 2 drawbacks do not seems much, or at least not "several". > > Can you maybe explain others issues so we can find a solution that work > > fine ? > > Sorry, there is just no solution that can make soname-suffixed libraries > work. That's still not explaining. 2 is not "several". And "I do not accept solution" is not the same as "there is no solution". -- Michael Scherer -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
