Hello, I personally can't comment on how much upstream improved after the last discussion (iirc, on kde-core-devel). However, it would be naive to think that we will never face BIC-without-SONAME-bump problems in the future. Solving them all upstream would be great but it's simply too optimistic scenario due to many factors.
Generally I can think of two ways of dealing with this. The first is our policy at the moment. 1. [ Package level ]. Rename the library package and add Breaks/Replaces against the previous versions, keep library SONAME (and filenames) unchanged. Pros: a) binary compatible with upstream and other distributions (at least in theory); b) ensures users have no old BIC libs (and apps linked to them) around. If an app ends up directly or indirectly linked to the old and new library with the same symbols, bad things may happen (e.g. recent libpng case and see below); c) does not require patching of upstream source. Cons: a) apt unfriendly because two library packages cannot be co-installed. Library packages are typically deep in the dependency chain so apt may require to force removal/installation in some cases; b) makes partial upgrade to new KDE releases very painful. I.e. it renders some 3rd party applications uninstallable due to conflicting library packages; 2. [ Library level ]. Change library SONAME (e.g. add debN suffix, specifics to be discussed) and rename the package. No Breaks/Replaces needed as there are no conflicting files. Pros: a) apt friendly as it's a recommended way to deal with SONAME changes; b) new KDE releases should no longer break 3rd party applications (at least at the package management level); Cons: a) custom SONAMEs and library filenames will be binary incompatible with the rest of the world; b) if conflicting libraries are loaded in the same app memory space (unlikely though), it might lead to crashes at runtime; c) crashes might occur due incompatibilities in the runtime client/server protocols (if there are ones); d) requires patching of upstream source (i.e. altering SOVERSION in the CMakeLists.txt); So what I am proposing is the switch to 2). I do believe that user experience is more important than SONAME compatibility with the rest of the world (which is theoretical anyway, at least in the KDE land). IMHO, other cons are not a big deal either as KDE is not libpng and runtime conflicts are more unlikely than likely. So what do you think and which way do you prefer? Maybe we could think of something better? -- Modestas Vainius <mo...@debian.org>
Description: This is a digitally signed message part.