On Tue, 2008-04-08 at 10:50 +0200, Salvatore Ansani wrote: > Hi mentors, > not a technical question this time :) > > I want to understand how to correctly handle various libs versions. > > Let me start with an example. > > Suppose a package, yet in debian unstable repo, currently depend on kdelibs5 > (4.0.2 for example). > If I upgrade my kde to 4.0.66+svn... I break all my dependencies and my old > package need to be removed. That is wrong. The libraries involved must be able to be installed side-by-side so you have libfoo1 and libfoo2. The -dev package can be from foo2 but the whole reason for SONAMEs in package names is to require that the old version is retained when a new SONAME becomes available. If you are talking about entire environments (and not just libraries), then maybe use a chroot but you cannot replace an entire environment in one go, you must replace the libraries first (with SONAME bumps), you must retain the old libraries so that the system keeps operating and you then ask each application to rebuild against the new -dev until you can finally remove the old library. Look at the Gtk1 to Gtk2 transition - it is PAINFUL but it is the only way of retaining a working system throughout. > Now the question... How I can handle this new build ??? Package is obviously > experimental but, if I change version with package_oldversion_SVNBLABLABLA, > I break some policy ??? If you *don't* change the SONAME you break policy. Policy is that a library MUST retain ABI/API compatibility if it is the same SONAME. This is done specifically so that libfoo1 can be retained during rebuilds to compatibility with libfoo2. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part