[ANNOUNCEMENT] Updated: libidn{, 12, -devel, -doc} mingw64-{x86_64, i686}-libidn 1.38

[Brian Inglis]

On 2021-08-04 06:41, Jon Turney wrote:
> On 03/08/2021 17:14, Brian Inglis wrote:
>> On 2021-08-03 09:56, Jon Turney wrote:
>>> On 02/08/2021 18:19, Cygwin libidn2 Maintainer wrote:
>>>> The following packages have been upgraded in the Cygwin distribution:
>>>>
>>>> * libidn            1.38
>>>> * libidn12            1.38
>>>> * libidn-devel        1.38
>>>> * libidn-doc            1.38
>>>> * mingw64-x86_64-libidn    1.38
>>>> * mingw64-i686-libidn    1.38
>>>>
>>>> and the following package has been obsoleted from the Cygwin 
>>>> distribution:
>>>>
>>>> * libidn11            1.33
>>>
>>> I've reverted that obsoletion, by removing 'obsoletes: libidn11' from 
>>> the hint for libidn12, since it apparently still has some uses.
> 
> ... and removed the empty libidn11-1.1.38-1 package (generated by 
> cygport for compatibility with obsolete versions of setup)
> 
> ... and added a 'replace-versions: 1.38-1' hint to libidn11 (in case 
> someone installed the above before I remembered to remove them)
> 
>> Can users just rerun Cygwin Setup so that it will update setup.ini and 
>> reinstall cygidn-11.dll?
> 
> Yes, that should fix any broken installs.
> 
>> Is obsoleting previous dlls something that we should not do on a 
>> package ABI break?
> 
> Correct, do not do that.
> 
> In this context, 'package A obsoletes package B' means 'package B 
> provides everything that package A did, so if A is installed, uninstall 
> A and install B'.
> 
> This behaviour is not unique to Cygwin packaging.
> 
>> How should maintainers handle such situations in cygport?
> 
> You don't need to mention the old soversion in the updated cygport at all.
> 
> (a heuristic in calm identifies old soversions, and exempts them from 
> the (annoying) "all install packages from a source package must have a 
> unique current version" check)
> 
> (Yes, that means that those old soversions, and the corresponding 
> source, linger in the repository indefinitely.  yselkowitz would 
> occasionally manually locate old soversions which aren't required by any 
> other package (or which could be made so with some rebuilds), and purge 
> them from the repo, but ... that service is no longer running :))

Thanks Jon for the fix.
*Sorry* to all users impacted to have caused the issue.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]