Hi,
On 10/8/24 16:01, Simon Josefsson wrote:
1) Take current non-OpenBSD 'signify' source package and upload NEW
'signify-mail' with d/control modified as:
Source: signify-mail
...
Package: signify-mail
Replaces: signify (<= 1.14-7)
Do we need 'Breaks: signify (<= 1.14-7)' too? Conflicts?
Conflicts, yes.
The Replaces+Conflicts combination is interpreted in a special way,
because normally it would be nonsensical: two packages cannot be
installed at the same time, but if they are, files from one take
precedence. So this is how to encode that one package should completely
replace another.
The overlap in files is not 100%, but that is fine, both apt and dpkg
know what to do.
The Conflicts needs to be versioned to allow the transitional package to
be installed.
2) Once 'signify-mail' has entered testing, open a ftp.debian.org RM bug
for 'signify' to get the binary packages removed from testing.
This should be done in unstable, not testing.
3) Open a wishlist bug for 'signify-openbsd' with a patch to provide a
'Package: signify' that has /usr/bin/signify and to add:
Conflicts: signify (<= 1.14-7), signify-mail
A package never needs to conflict with an older version of itself. The
conflict with signify-mail is needed only if there is a file name conflict.
Adding the OpenBSD signify under the name "signify" in the trixie cycle
is a bad idea, because existing installations would switch to that.
Instead, signify-mail should provide a transitional binary package
"signify" that pulls in signify-mail. This also overwrites a binary
package from the earlier "signify" source package, and if no other
binaries remain, normal archive cleanup catches that, so no RM is
needed. If other binaries remain, a RM is needed for unstable.
BTS entries can start migrating here as well.
In trixie+1, the transitional binary package is removed (no longer built
from the source package), which, again, does not need an RM.
OpenBSD signify can rename its source package if they want, it does not
matter to users. If they do, BTS entries on the source package should
also be migrated.
In trixie+2, openbsd-signify binary package is renamed to signify (with
Depends+Replaces+Conflicts), and a transitional package added to pull it in.
Is a similar Breaks needed too?
Breaks is a Conflicts that does not affect installation ordering
(because there is no actual file conflict, so unpacking in any order is
allowed). If Replaces is in place, ordering no longer matters.
The 'signify-openbsd' binary package should be left around as a empty
dummy package for transitions to the new 'signify' binary package.
In trixie+2, yes. It should be removed in trixie+3.
Yes, that's a long timeline.
Simon
