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.
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.
> 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.
> 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.
> 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.
S
