Le mardi 05 mars 2013 à 23:26 +0100, Kevin Kofler a écrit : > Olav Vitters wrote: > > Mageia packages libraries by the .so major version. So you can upgrade a > > library and then work on rebuilding all the software. > > > > Example (library name is not too important): > > lib64spice-client-gtk3.0_1-0.9-1.mga2 > > lib64spice-client-gtk3.0_4-0.15-3.mga3 > > This is a really ugly hack which has several drawbacks, e.g.: > * the one you already cited: > > Obvious drawback is making 'yum' (or whatever) intelligent enough to > > automatically remove those libraries. > (and in particular, how to ensure that it removes only old libraries and not > packages the user actually wants which just happen to not be Required by > anything anymore). keeping unused library is not worst that keeping old perl modules. 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. The priority for rawhide should be having something that work first. 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 fact that this makes the package names much less user-friendly. E.g., > soname-based package naming is particularly confusing for kdelibs, where you > end up with kdelibs4 actually being kdelibs 3 and kdelibs5 being kdelibs 4. > (What we use for kdelibs in Fedora is 1. suffixes reflecting the actual > major version, not the soname version and 2. the default kdelibs has no > version suffix at all, though it Provides: kdelibs4 and we recommend that > packages Require/BuildRequire kdelibs4(-devel) rather than kdelibs-devel.) 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. 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 ? -- Michael Scherer -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
