Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#51650 closed enhancement (fixed)

gnupg21 @2.1.12_0: install symlinks for "gpg" and "gpgv"

Reported by: larryv (Lawrence Velázquez) Owned by: roederja
Priority: Normal Milestone:
Component: ports Version: 2.3.99
Keywords: haspatch Cc: Ionic (Mihai Moldovan)
Port: gnupg21

Description

It would be nice if this port installed symlinks for gpg and gpgv. Users could invoke the suffixless binaries as they’re used to, and gnupg21 could satisfy bin and path dependencies like the one in keybase.

The attached patch simply imitates the “package” phase of the current ArchLinux package. I made it against @2.1.12_0, but I’d recommend committing it as part of the 2.1.13 update.

Attachments (1)

gnupg21.symlinks.patch (891 bytes) - added by larryv (Lawrence Velázquez) 8 years ago.
install suffixless symlinks

Download all attachments as: .zip

Change History (10)

Changed 8 years ago by larryv (Lawrence Velázquez)

Attachment: gnupg21.symlinks.patch added

install suffixless symlinks

comment:1 Changed 8 years ago by roederja

The reason why gpg 2.* is not installed as gpg is that you can install it alongside gpg 1.* . This may be less relevant now though.

comment:2 Changed 8 years ago by Ionic (Mihai Moldovan)

Given that we conflict gnupg, gnupg2, gpg-agent and gnupg21, creating such symlinks in gnupg21 is okay.

We can't do this in gnupg2 because users can have both gnupg and gnupg2 installed, though, so the behavior of the gpg and gpgv binaries will be unreproducible without knowing the system state first. Not sure we want that, larry?

comment:3 Changed 8 years ago by roederja

No sym link is required if we want this. There is a configure switch to install the binary as just gpg. I would keep everything as is though. Changing it will just break things.

comment:4 in reply to:  3 Changed 8 years ago by larryv (Lawrence Velázquez)

Replying to jann@…:

No sym link is required if we want this. There is a configure switch to install the binary as just gpg.

Doesn’t that option cause the build to NOT install gpg2? I don’t think that’s what any of us want.

comment:5 in reply to:  2 Changed 8 years ago by larryv (Lawrence Velázquez)

Replying to ionic@…:

We can't do this in gnupg2 because users can have both gnupg and gnupg2 installed, though, so the behavior of the gpg and gpgv binaries will be unreproducible without knowing the system state first. Not sure we want that, larry?

I hadn’t considered that. I wouldn’t call that state of affairs unreproducible (gnupg and gnupg21 would always install gpg and gnupg2 would never do so), but it certainly could be confusing. It’s easy for someone to understand why 1.x installs gpg and 2.x installs gpg2; it would be harder to understand why 1.x and 2.1.x installed gpg but 2.0.x did not. I’d understand if you wanted to close this at wontfix.

(My personal motivation is getting keybase working with something that isn’t gnupg, but perhaps it’d be better to patch that instead of this.)

comment:6 Changed 8 years ago by roederja

So keybase only works if the binary (or symlink) is called gpg ?

comment:7 in reply to:  6 Changed 8 years ago by larryv (Lawrence Velázquez)

The Keybase software itself can find “gpg2” (and actually prefers it), but our keybase port currently has a bin:gpg:gnupg dependency.

comment:8 Changed 7 years ago by l2dy (Zero King)

Resolution: fixed
Status: newclosed

comment:9 Changed 7 years ago by l2dy (Zero King)

Since 2.1.23:

  • gpg: "gpg" is now installed as "gpg" and not anymore as "gpg2". If needed, the new configure option --enable-gpg-is-gpg2 can be used to revert this.
Note: See TracTickets for help on using tickets.