Hi, On 10/9/24 18:02, Simon Josefsson wrote:
x) Take current non-OpenBSD 'signify' source package and upload NEW 'signify-mail' package, say version 1.14-8 (?), that provides /usr/bin/signify-mail instead of /usr/bin/signify, and has d/control:
Source: signify-mail ... Package: signify-mail Replaces: signify (<= 1.14-7) Conflicts: signify (<= 1.14-7)
Yes.
Package: signify Depends: signify-mail
Yes.
Breaks: signify (<= 1.14-7) Replaces: signify (<= 1.14-7) Provides: signify
These are unnecessary, because that *is* the "signify" package. It cannot be installed in parallel with an older version of itself, it replaces files in an older version of itself, and it satisfies dependencies on "signify", without any relationships declared.
The short description of the transitional package should begin with "Transitional package" or something like this so it is immediately obvious in a package list without opening a detail page.
x) Normal archive cleanup should remove the old 'signify' package. If this doesn't happen, once 'signify-mail' has entered testing, open a ftp.debian.org RM bug for the old package 'signify' to get the binary packages removed from unstable.
Not sure about the timeframe of normal archive cleanup (it is a manual process triggered by an automated check).
Only the "signify" source package needs to be removed, as the "signify" binary package is now provided by the "signify-mail" source package, which leaves the "signify" source package with no binary packages.
x) File a wishlist bug for 'signify-openbsd' (with patch) to ALSO provide /usr/bin/signify (hardlink?), and to add a: Conflicts: signify (<= 1.14-7)
Yes.
Could it be a 'Conflicts: signify' to get the transitional dummy package removed after installing 'signify-openbsd'? Or does that just break upgrades?
That just breaks upgrades.
x) File a bug to suggest a trixie release note saying that the non-OpenBSD 'signify' package has been rename to 'signify-mail', and provides /usr/bin/signify-mail instead.
Yes. I believe there is also a way to have a notice show up in apt-listchanges, but I don't exactly remember what triggers that (urgency?).
x) Open a bug for 'signify-mail' to say that the transitional package should be removed in trixie+1.
Yes.
x) Open a wishlist bug for 'signify-openbsd' (with patch) to track that in trixie+1 (+2?) it should provide a 'Package: signify' that has /usr/bin/signify and to add:
Ideally, +2, so users will see a release with no "signify" package, which causes it to be listed under "Obsolete/Local Packages" in aptitude.
Conflicts: signify (<= 1.14-7)
Yes, because there is a file name conflict.
Replaces: signify (<= 1.14-7)
No, because package managers should not treat this as a replacement for older versions of signify.
The 'signify-openbsd' binary package should be left around as a empty dummy package for transitions to the new 'signify' binary package: Package: signify-openbsd Depends: signify
Yes.
Breaks: signify-openbsd (<= x.y.z) Replaces: signify (<= x.y.z) Provides: signify
No. It cannot be co-installed with older versions of itself (so Breaks does nothing), it does not provide any files that could conflict (so Replaces does nothing), and it does not provide the same functionality as the "signify" package (so Provides is wrong).
Not sure when it makes sense to drop /usr/bin/signify-openbsd from the 'signify' package? trixie+1?
It could be left as a symlink in the transitional package, that way people can easily remove it from their PATH after they have adjusted their scripts, and it goes away when trixie+3 drops the transitional "signify-openbsd" package.
x) OPTIONAL: Open a wishlist bug for 'signify-openbsd' to, after trixie, upload itself as a NEW 'signify' source package and to ask for removal of the old 'signify-openbsd' source package. It was suggested this can trigger BTS bugs, so may not be worth doing. It doesn't really gain anything except aesthetics.
I'd still do that, but in trixie+2, when the package takes over the "signify" binary package name as well. Moving the old bug reports to "signify-mail" source/binary packages can be done as soon as these exist in unstable, that also avoids most of the BTS trouble (which is basically "the BTS does not release-track Maintainer information").
x) Open a wishlist bug for the OpenBSD signify package to remove the transitional 'signify-openbsd' package for trixie+2 (+3?). The /usr/bin/signify-openbsd name is then also removed.
+3. The transitional package is released with +2, and people upgrade to that version when upgrading between stable releases. This way, they receive the package with the "Transitional package..." description, which then shows up in "Obsolete/Local Packages" in +3.
Removing it in +2 would mean that people never receive a package with this description.
Simon
