Ansgar <[email protected]> writes: > Section 8.1 starts with the following:
> +--- > | The run-time shared library must be placed in a package whose name > | changes whenever the SONAME of the shared library changes. This > | allows several versions of the shared library to be installed at the > | same time [...] > +--- > This has two issues: > 1. It is not needed to change package names for this. One can also use > "Provides: <something-that-changes-with-soname>" and have packages > depend on that. I don't understand this objection. The reason why the name of the package needs to change is that for a normal upgrade transition that doesn't require a lockstep upgrade, you have to be able to install version 1 and version 2 (SONAMEs) of the library at the same time, and the only way that is possible in Debian's packaging system is if either they are both included in the same package (usually not a good idea since the different versions come from different versions of the source package, and certainly not the common approach) or if the package name is different. Provides is of no help here whatsoever so far as I can see. What am I missing? > 2. It does not allow coinstallability without other constraints. There > are several common patterns like depending on a libfoo-bin or > libfoo-common package which then would also be required to work with > both versions. If I understand correctly, the issue that you're raising is that in practice this is more of a should than a must, and sometimes we do let the shared libraries conflict and thus require each system do an all-or-nothing upgrade of everything that depends on that shared library. I agree that we do sometimes do this, but hopefully you also agree that this is not desired and we *should* allow coinstallability? (Should, not must.) If I understand that correctly, I would be in favor of spelling that out more explicitly if someone proposes good replacement wording. However, just to be clear (since I wasn't completely sure what you were proposing), embedding the SONAME of the library in the package version *is* a must and has been for as long as I've been working on Debian, and I'm opposed to relaxing that even if the versions of the library conflict for some reason. That is a valuable convention that a lot of people implicitly rely upon and we shouldn't weaken it even if it can't always produce all the properties we desire. > I think I've also seen libfooX-bin packages that were not coinstallable > as helper binaries were not installed into a path that changes with > soname. Yes, that would be a good thing to state explicitly as well. I think the constraint is that either the helpers need to work with both versions of the library, or they need to use different paths for the different versions, or if neither of those cases are possible, then you're in the situation where they sadly need to conflict, but it would be best to avoid this. > There is also a footnote that states > +--- > | There are some exceptional situations in which co-installation of > | two versions of a shared library is not safe, and the new shared > | library package has to conflict with the previous shared library > | package. This is never desirable, since it causes significant > | disruption during upgrades and potentially breaks unpackaged > | third-party binaries, but is sometimes unavoidable. These situations > | are sufficiently rare that they usually warrant project-wide > | discussion, and are complex enough that the rules for them cannot be > | codified in Debian Policy. > +--- > which seems to contradict current practice as I don't remember a > single project-wide discussion about -common or -bin packages cuasing > this. I don't recall a specific discussion off the top of my head, so maybe there's a better way to phrase this that doesn't imply there's a requirement to discuss it on debian-devel. But I do think that paragraph reflects current practice in its general thrust: The normal practice is to ensure that different shared library versions are coinstallable so that upgrade transitions are easier, it's unfortunate when that's not possible, and we try to avoid the disruption of having the library packages conflict when we can. > So I suggest: > 1. Policy should document current practices and also allow other > methods that ensure dependencies are satisfied. Note that some > ecosystems like Perl do similar things with perlapi-X (where different > perlapi-X providers are in general not coinstallable). That would be great. Wording suggestions welcome. > 2. Coinstallability should be mentioned as a concern for libraries > with many reverse dependencies, but should explictly state that this > requires the entire dependency chain to be coinstallable. Note that > "Depends: libfoo-common (>= X)" runs into the risk that newer > libfoo-common packages break older library versions and are safe only > when extraordinary care is taken; the same is true for > "libfoo-bin". (One could use libfooX-common, libfooX-bin packages > where data and helper binaries are installed into paths that change > with the SONAME such as /usr/lib/libfooX/libfoo-helper.) I generally agree with this but disagree with the "many reverse dependencies" part. This is our standard packaging practice for all shared libraries. > 3. The footnote about "exceptional situations" should be removed. I'm opposed to removing the discussion in the footnote, but better wording is always welcome. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
