On 2021-05-24 Simon Josefsson <si...@josefsson.org> wrote:
> Hi! This is for post-bullseye, but I appreciate guidance if anyone has
> time. Shared library version transitions trigger uncertainty in me.
> I want to upload a new upstream libidn release into Debian, but upstream
> has done a shared library transition.
Hello Simon,
I will assume that "shared library transition" means that that libidn
1.34 will have a soname bump (libidn12.so) but that the new release is
API compatible. The following assumes this is true ...
> Bullseye will ship with
> libidn11-dev instead of libidn-dev too. Is the first step on the
> transition to provide a libidn-dev package experimental (and after the
> release, unstable) and make all reverse build-dependencies use it?
That would delay the whole thing unnecessarily, you would not want to
artificially make changing all rdeps a pre-dependency of your work
First off if the new version of libidn is API compatible with 1.33 there
will be no hard /requirement/ for renaming libidn11-dev to libidn12-dev.
You could have libidn11-dev as a dev-package for libidn12. It is not
aesthetically pleasing and confusing but would continue to work and has
the least potential for error. OTOH a soname bump is good time for
renaming the development package since you will have a new binary
package (libidn12) and will need to go through NEW processing anyway.
However you should do soname bump and dev-package rename in one upload
(to experimental) instead of beforehand. This ways ftp-master will only
need to check it once. So you would use this timelime:
1. Prepare packages of the new upstream targeted for experimental
(libidn12, libidn-dev, libidn11-dev transition package). Test.
2. Upload to experimental.
3. Wait for NEW processing
4. Do some more tests, once you thinks all rdeps could be built against
libidn12 you request a transition slot. Please note that at this point
no source changes to rdeps related to packaging changes needed to happen,
they can (and should) continue to b-d on libidn11-dev which pulls in the
libidn-dev.
5. debian-release gives you the GO for uploading the package to testing.
6. You do this and debian-release triggers rebuilds of all rdeps.
7. All rebuilt rdeps and libidn12/libidn-dev/libidn11-dev propagate to
testing together 10 days later.
8. Now you can start submitting bug-reports against rdeps asking for a
change of the b-d.
[...]
> A 'git diff' between the version in bullseye and what I want to upload
> to experimental is shown below, together with debdiff-output between the
> built packages.
> Generally, does things looks okay? Specifically, what about the
> Breaks/Replaces/Conflicts? The d/changelog entry? Will the confusing
> 'Replaces: libidn11-dev' for the libidn11 (!) package in bullseye cause
> any problem? Am I right to drop it here?
> Package: libidn11-dev
> +Section: oldlibs
> +Architecture: any
> +Depends: libidn-dev, ${misc:Depends}
I would use (= ${binary:Version}) for the depends to make sure that
libidn11-dev 1.38 together with libidn-dev 1.34 do not fullfill a
dependency on libidn11-dev (>= 1.35)
> +Package: libidn-dev
> Section: libdevel
> Architecture: any
> Depends: libidn11 (= ${binary:Version}), pkg-config, ${misc:Depends}
> -Conflicts: libidn9-dev
> +Breaks: libidn11-dev (<< 1.33-4)
> +Replaces: libidn11-dev (<< 1.33-4)
> +Provides: libidn11-dev
> Multi-Arch: same
> Description: Development files for GNU Libidn, an IDN library
You should drop the Provides - It is superfluous since you have got a
libidn11-dev transition package.
hth, cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
