Attempting to summarize this thread into actions - please correct me when I misunderstood:
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? I've re-read chapter 7 of the policy manual again, but I have read it so many times before and still don't feel confident about what it actually means. https://www.debian.org/doc/debian-policy/ch-relationships.html 2) Once 'signify-mail' has entered testing, open a ftp.debian.org RM bug for 'signify' to get the binary packages removed from 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 Is a similar Breaks needed too? The 'signify-openbsd' binary package should be left around as a empty dummy package for transitions to the new 'signify' binary package. 4) Uploading source package 'signify-openbsd' to NEW as 'signify', and then ask for removal of the old 'signify-openbsd' source package. This is nice but optional. It was suggested this can trigger BTS bugs. It may be best to wait until at least trixie+1. This doesn't affect users so is more of an developer aesthetic concern, which may suggest it isn't worth doing at all. /Simon
signature.asc
Description: PGP signature
