[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Planning for libidn shared library version transition

On 2021-05-24 Simon Josefsson <simon@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
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'

Reply to: