GnuPG in Guix

GnuPG in Guix

[g33k0b0y .]

It seems that Guix can install multiple versions of GPG. It names the
1.4.18 version as gpg, and the 2.0.26 version as gpg2.

There is a problem, however.

By default Guix installs the highest version, which is 2.0.26.
However, an potential newbie could try calling it through bash as gpg.
This won't work, as it hasn't installed gpg version 1.4.18 and
therefore is expecting only gpg2 as its command. This is not made
clear to the user.

If I  am an inexperienced user and install gnupg, from my previous
experience with other distros, (Trisquel, gNewSense) I would expect to
use gpg to call it. Imagine my surprise when bash says command not
found! I am never told to use gpg2 as the command, nor would I think
of it.

How can we improve this?

Re: GnuPG in Guix

[Ricardo Wurmus]

g33k0b0y . writes:

> It seems that Guix can install multiple versions of GPG. It names the
> 1.4.18 version as gpg, and the 2.0.26 version as gpg2.

[...]

> If I  am an inexperienced user and install gnupg, from my previous
> experience with other distros, (Trisquel, gNewSense) I would expect to
> use gpg to call it. Imagine my surprise when bash says command not
> found! I am never told to use gpg2 as the command, nor would I think
> of it.

On Fedora 21, /usr/bin/gpg2 is installed by the package for version
2.x.x (gnupg2-2.0.25-2) and /usr/bin/gpg is installed by the package for
version 1.x.x (gnupg-1.4.18-4).  I would not expect to use /usr/bin/gpg
when I installed gnupg2, because that only comes with /usr/bin/gpg2.

I happen to have both installed on my Fedora system.

I do not think that we should override upstream's decision to call these
executables by a different name.

~~ Ricardo

Re: GnuPG in Guix

[Taylan Ulrich Bayırlı/Kammer]

"g33k0b0y ." <g33k0b0y@gmail.com> writes:

> It seems that Guix can install multiple versions of GPG. It names the
> 1.4.18 version as gpg, and the 2.0.26 version as gpg2.
>
> There is a problem, however.
>
> By default Guix installs the highest version, which is 2.0.26.
> However, an potential newbie could try calling it through bash as gpg.
> This won't work, as it hasn't installed gpg version 1.4.18 and
> therefore is expecting only gpg2 as its command. This is not made
> clear to the user.
>
> If I  am an inexperienced user and install gnupg, from my previous
> experience with other distros, (Trisquel, gNewSense) I would expect to
> use gpg to call it. Imagine my surprise when bash says command not
> found! I am never told to use gpg2 as the command, nor would I think
> of it.
>
> How can we improve this?

My first instinct when a command I expect to be found isn't found is to
try to tab-complete it in some way, because it happens occasionally that
a CLI command has a different name than one would expect, indeed often
because of such version issues.

So I'd have thought it's fine, and people should get used to it; GPG
isn't unique or rare in this regard.  I think Debian does the same too.

Taylan

Re: GnuPG in Guix

[Mark H Weaver]

"g33k0b0y ." <g33k0b0y@gmail.com> writes:

> It seems that Guix can install multiple versions of GPG. It names the
> 1.4.18 version as gpg, and the 2.0.26 version as gpg2.
>
> There is a problem, however.
>
> By default Guix installs the highest version, which is 2.0.26.
> However, an potential newbie could try calling it through bash as gpg.
> This won't work, as it hasn't installed gpg version 1.4.18 and
> therefore is expecting only gpg2 as its command. This is not made
> clear to the user.
>
> If I  am an inexperienced user and install gnupg, from my previous
> experience with other distros, (Trisquel, gNewSense) I would expect to
> use gpg to call it. Imagine my surprise when bash says command not
> found! I am never told to use gpg2 as the command, nor would I think
> of it.
>
> How can we improve this?

On Debian and its derivatives (which include both Trisquel and
gNewSense), gnupg-1.4 and gnupg-2.0 have different package names, not
just different version numbers.  I think that perhaps we should do the
same.

Apart from the issue that raised above, another issue is that one cannot
currently use "guix package -u" if one prefers to use gnupg 1.4.x,
because it will always try to update to 2.0.x, and soon it will try to
upgrade all of us to 2.1.x, which not everyone will want (at least not
right away) because it brings new incompatible changes.

In the case of gnupg, 1.4.x and 2.0.x are really two different programs,
despite their similarity and common heritage.

       Mark

Re: GnuPG in Guix

[Andreas Enge]

On Thu, Feb 26, 2015 at 10:59:05AM -0500, Mark H Weaver wrote:
> Apart from the issue that raised above, another issue is that one cannot
> currently use "guix package -u" if one prefers to use gnupg 1.4.x,
> because it will always try to update to 2.0.x, and soon it will try to
> upgrade all of us to 2.1.x, which not everyone will want (at least not
> right away) because it brings new incompatible changes.

This is a different problem, I think: that one cannot specify packages
to not upgrade on the command line. I think there may be any number of
reasons to keep an older version of a package. So it would be nice if
one could write something like
   guix package -u '*' -nu 'python-*'
for instance (where "-nu" stands for "not update").

Andreas

Re: GnuPG in Guix

[Andreas Enge]

On Thu, Feb 26, 2015 at 10:59:05AM -0500, Mark H Weaver wrote:
> On Debian and its derivatives (which include both Trisquel and
> gNewSense), gnupg-1.4 and gnupg-2.0 have different package names, not
> just different version numbers.  I think that perhaps we should do the
> same.

Well, that is a different design decision in debian, because I think their
package manager does not allow to install two versions of a package with
the same name at the same time. In guix, I can issue without problem
   guix package -i qt-4.8.6 qt

The argument of incompatible changes would hold for almost everything,
since usually libfoo-x.y.z is incompatible with libfoo-a.b.c for x>a.

Andreas

Re: GnuPG in Guix

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

> I do not think that we should override upstream's decision to call these
> executables by a different name.

+1

Mark H Weaver <mhw@netris.org> skribis:

> Apart from the issue that raised above, another issue is that one cannot
> currently use "guix package -u" if one prefers to use gnupg 1.4.x,
> because it will always try to update to 2.0.x, and soon it will try to
> upgrade all of us to 2.1.x, which not everyone will want (at least not
> right away) because it brings new incompatible changes.

This is a different issue, but yes, maybe the “old” one should have its
name changed to “gnupg1”.  What do people think?

Thanks,
Ludo’.

Re: GnuPG in Guix

[Mark H Weaver]

Andreas Enge <andreas@enge.fr> writes:

> On Thu, Feb 26, 2015 at 10:59:05AM -0500, Mark H Weaver wrote:
>> Apart from the issue that raised above, another issue is that one cannot
>> currently use "guix package -u" if one prefers to use gnupg 1.4.x,
>> because it will always try to update to 2.0.x, and soon it will try to
>> upgrade all of us to 2.1.x, which not everyone will want (at least not
>> right away) because it brings new incompatible changes.
>
> This is a different problem, I think: that one cannot specify packages
> to not upgrade on the command line. I think there may be any number of
> reasons to keep an older version of a package. So it would be nice if
> one could write something like
>    guix package -u '*' -nu 'python-*'
> for instance (where "-nu" stands for "not update").

I agree.  However, in this case, I *do* want upgrades, to the latest
1.4.x that is.  In fact, they are probably very important whenever they
happen.

      Mark

Re: GnuPG in Guix

[Andreas Enge]

On Thu, Feb 26, 2015 at 06:16:12PM +0100, Ludovic Courtès wrote:
> This is a different issue, but yes, maybe the “old” one should have its
> name changed to “gnupg1”.  What do people think?

I think that is a severe regression and would open a can of worms. If we do
it for one package, why not for all where we have several versions in our
distribution? Or even for all packages... For this, we have the version
number, which we should not duplicate in the name.

For gnupg in particular, notice that it is considered as _one_ project
upstream, with several branches: called "GnuPG stable", "GnuPG modern",
"GnuPG classic".

I think that one of the advantages in guix is that we have generally easily
predictable package names, directly derived from the upstream names.
If I want to install libxext, I can do
   guix package -i libxext
On debian, in contrast
   apt-get install libxext
   E: Unable to locate package libxext
because it is called libxext6.
For gmp, we just do "guix package -i gmp", or "guix package -i gmp-x.y.z".
In debian, there are packages
libgmp10
libgmp10-doc
libgmp-dev
libgmp3-dev
Just because debian cannot install several versions of the same package.
More than once this has unnerved me, and I find the guix way of not messing
with package names really refreshing. It is maybe not revolutionary, but part
of our philosophy of diverging as little as possible from upstream.

That said, I think it would be important to find a solution to the problem
of incidental upgrades, a way of pin pointing packages one does not want
to upgrade to a newer version.

Andreas