On Friday, July 8, 2011, Allan McRae <[email protected]> wrote: > On 08/07/11 23:55, Dan McGee wrote: > > On Fri, Jul 8, 2011 at 6:59 AM, Allan McRae<[email protected]> wrote: > > The conversion to using parse_options causes this option to break. > It is preferable to remove the option rather than fix it as it is > simply a wrapper for "gpg --homedir @sysconfdir@/pacman.d/gnupg". > Any user using more advanced keyring management than provided by > pacman-key can manage to point gpg at the right place themselves... > > How to manually edit the keyring with gpg will instead be documented > in the man page in a later commit. > > > I won't lie here, I'm not a fan of this but maybe because I've become > accustomed to the option being available. It was way easier than > typing out the long-form gpg command line. "pacman-key --adv --verify > /tmp/cryptsetup-1.3.1-1-x86_64.pkg.tar.xz.sig" is something I just > pulled out of my command history. > > What if we just enforced instead that the entire arg string was quoted: > pacman-key --adv "--verify /tmp/cryptsetup-1.3.1-1-x86_64.pkg.tar.xz.sig" > Or perhaps the "don't parse anymore" option: > pacman-key --adv -- --verify > /tmp/cryptsetup-1.3.1-1-x86_64.pkg.tar.xz.sig > > > > The latter would work, but I am still not entirely convinced about the need > for this... > > I intend to add a --verify option to pacman-key because I think that would be > a fairly common command to use. Anything else with common usage should also > be added to pacman-key. > > Is there anything else you used this for? I just have this nagging feeling > that hiding what gpg is doing (we already have --no-permission-warning there > by default) is not the way to go. Not that my opinion is overly strong on > this.
That works too- if we add a --verify then I'm fine with this patch. The --no-perm-warn is likely something we can/should move to a default gpg.conf file. -Dan
