On 21 September 2015 at 14:02, Simon McVittie wrote: | On 21/09/15 13:30, Dirk Eddelbuettel wrote: | > | The solution is to change something that is part of the Debian | > | packaging: the package name. | > | > So is the trailing '1'. | | "libquantlib1" would be the correct name for a Debian package containing | the SONAME (upstream-chosen ABI designation) "libquantlib.so.1". It is | not the correct name for a Debian package containing "libquantlib.so.0". | | Under normal circumstances, the Debian package name and the SONAME | should be mechanically derivable from each other: libquantlib0 <-> | libquantlib.so.0. Lintian will complain if this is not the case, for | instance.
I've maintained this for maybe fourteen years. Upstream just doesn't set or change soname majors, so it is still my degree of freedom... | When awkward transitions like this result in the ABI of the Debian | package changing without anything having changed upstream, we append a | suffix: libfoo0g (libc5 -> glibc transition, many years ago), | libfoo0c102, libfoo0c2, libfoo0c2a, and now libfoo0v5. Those suffixes | are centrally chosen (usually by the g++ maintainer, because C++ is the | usual reason to need one) and Lintian has some special cases for them, | so they don't need to be overridden. Good point re lintian. | > As you're subtly hinting that I should rather use libquantlib0v5 I may do | > so. It is just 'uglier' but common ... | | Please do. The release team, and the people like me who are helping them | with this train-wreck of a transition, have had to deal with hundreds of | similar transitions. Please help us to do that by making this one like | the others, unless there is a compelling reason why it needs to be | different. Consistency helps, I agree. | > I may get myself confused by the names (I find '(old)stable', 'testing' and | > 'unstable' simpler to use). | | I was deliberately using "jessie" and "stretch" rather than the aliases, | because the primary purpose of Debian testing and unstable is to produce | stable releases, and the most likely reason for a current jessie | (stable) user to upgrade to stretch is that stretch has become the new | stable. | | > And both testing and unstable have the correct pair: quantlin 1.6.2-1 and | > quantlib-swig 1.6.1-1 (upstream needed a QL only fix, hence 1.6.2 there). | > | > Neither one will make it to (old)?stable. Only forcing by the user | > would. And then they get what they asked for... | | When the user upgrades from jessie (Debian 8, currently stable) to | stretch (Debian 9, currently testing), any upgrade path between the two | that is not forbidden by dependencies is meant to be valid. | | Sure, the quantlib currently in stretch will never enter jessie. That's | not the point. The point is that a user who is currently running jessie | will want to upgrade to stretch, and at that point - perhaps only very | briefly, or perhaps for an extended period of time - their system will | have a mixture of jessie and stretch (a "partial upgrade"). Part of our | job as package maintainers is to ensure that package dependencies forbid | partial upgrades that result in broken packages. It is my understanding from 20 years with dpkg et al that the Depends >= achieve this. Remember: this is one library package with two leaf dependencies. The more forceful conflicts etc of course also help. | > Yes, 'Conflicts:' and 'Replaces:'. Or 'Breaks:' and 'Replaces:' ? I have an | > old Breaks from a decade ago: | > | > Breaks: libquantlib-1.1, libquantlib-1.0.0 | > Replaces: libquantlib-1.2, libquantlib-1.1, libquantlib-1.0.0 | > Provides: libquantlib-1.2, libquantlib-1.1, libquantlib-1.0.0 | | The Ubuntu developers who prepared the initial batch of v5 transitions | mostly used Conflicts/Replaces. I don't know a specific rationale for | that, although I've seen mention of versioned Breaks and non-versioned | Conflicts usually being correct. The most important thing is that you | have Replaces combined with a negative relationship. That was from my Debian sources and its debian/control. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
