Andreas Metzler <ametzler@bebt.de> writes:
> 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 ...
Hi. Thanks for review!
For all practical matters, yes, it is completely API compatible, the
only thing that changed was this struct (that should never have been in
the public .h anyway) that changed from:
struct Stringprep_table
{
Stringprep_profile_steps operation;
Stringprep_profile_flags flags;
const Stringprep_table_element *table;
};
typedef struct Stringprep_table Stringprep_profile;
into:
struct Stringprep_table
{
Stringprep_profile_steps operation;
Stringprep_profile_flags flags;
const Stringprep_table_element *table;
size_t table_size;
};
typedef struct Stringprep_table Stringprep_profile;
Arguably, doing a soname bump for this minor change could probably have
been avoided, but this was back in 2018 and other distributions have
upgraded to newer libidn. If we revert the soname upstream now, it will
cause a lot of problems for others, so I don't think that is a good
idea.
We could patch upstream in Debian to avoid the soname bump, but that is
rather confusing. It is good timing now to fix this once bullseye is
released, so I think we should just do that.
>> 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.
That (and your suggestions below) seems good. I like it better than my
approach. I'll start to implement this and post a debdiff for review
before actually making the upload into experimental.
/Simon
> [...]
>> 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
>
>
Attachment:
signature.asc
Description: PGP signature