Paul Gevers <elbrus@debian.org> writes: > Hi > > On 08-10-2024 09:01, Simon Josefsson wrote: >> 3) Open a wishlist bug for 'signify-openbsd' with a patch to provide a >> 'Package: signify' that has /usr/bin/signify and to add: > > Do I understand correctly that signify-mail will also provide a > /usr/bin/signify? Yes that was my idea. But maybe that is a bad idea. > That's not allowed if the binaries have different functionality [1], > not even if the packages conflict. So apart from the name of the > packages, also the path needs to adapted. Good catch. This seems to warrant a trixie release note, to say that the non-OpenBSD 'signify' package's '/usr/bin/signify' has been renamed to '/usr/bin/signify-mail', and (hopefully also) that the plan for trixie+1 is for the OpenBSD 'signify-openbsd' source package to provide a /usr/bin/signify. That would also make the two packages co-installable going forward, which is good. This will break people's scripts, unless they read the release notes and modify their calls to 'signify' into 'signify-mail'. Interestingly that our processes makes something this simple (renaming a tool) so complicated to achieve. Another option is to remove the current non-OpenBSD 'signify' package that hasn't seen a single update in upstream CVS since 2004. What is the criteria for keeping a package around when doing so requires a lot of work from people who have no interest in the particular package, and nobody who is interested in the particular package steps up to do the work? Still, the goal of having a OpenBSD /usr/bin/signify is worth spending time on this for me. I'll try to provide a revised plan after parsing Simon Richter's e-mail. Or maybe two plans, one for removal, and one for renaming the package and tool. /Simon
Attachment:
signature.asc
Description: PGP signature