From: Jon Turney <jon.turney@dronecode.org.uk>
To: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>,
The Cygwin Mailing List <cygwin@cygwin.com>
Subject: Re: [ANNOUNCEMENT] Updated: libidn{, 12, -devel, -doc} mingw64-{x86_64, i686}-libidn 1.38
Date: Wed, 4 Aug 2021 13:41:55 +0100 [thread overview]
Message-ID: <9db380d9-c314-3e87-9aa1-b71d96aafd95@dronecode.org.uk> (raw)
In-Reply-To: <e2a20fe9-4de5-4ff8-e1da-79f415c51b03@SystematicSw.ab.ca>
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 :))
> I would like to know the correct approach to take to mitigate this and
> future such situations, before I create a libidn -2 package release.
next prev parent reply other threads:[~2021-08-04 12:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-02 17:19 Cygwin libidn2 Maintainer
2021-08-03 15:56 ` Jon Turney
2021-08-03 16:14 ` Brian Inglis
2021-08-04 12:41 ` Jon Turney [this message]
2021-08-04 15:40 ` Brian Inglis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9db380d9-c314-3e87-9aa1-b71d96aafd95@dronecode.org.uk \
--to=jon.turney@dronecode.org.uk \
--cc=Brian.Inglis@SystematicSw.ab.ca \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).