[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#45632] [PATCH] guix package: Warn if uses has 'guix' package in pro
From: |
Jakub Kądziołka |
Subject: |
[bug#45632] [PATCH] guix package: Warn if uses has 'guix' package in profile. |
Date: |
Thu, 07 Jan 2021 18:58:14 +0100 |
On Thu Jan 7, 2021 at 6:56 PM CET, zimoun wrote:
> Well, if the conflict is between the package 'guix' and the 'upgrade'
> command, then the warning should be there, IMHO.
The upgrade command is not part of the problem here, the same can be
observed if you use 'guix package -m' instead.
You avoid the problem by putting ~/.config/guix/current/bin first in
your path. I just checked, and that is the default on Guix System.
However, on a foreign distro, ~/.guix-profile/bin will be first in $PATH
unless the user intervenes with manual configuration.
In light of this, perhaps a better solution would be to unify the
profile loading in foreign-Guix's /etc/profile/guix.sh with Guix
System's /etc/profile?
The problem with that is, /etc/profile/guix.sh is only created once by
guix-install.sh, and doesn't get updated... perhaps *this* is something
worth fixing, to start with?
> > How about warning on pull instead? That should address the ‘halp,
> > me Guix be Benjamin Buttonin'’ support calls that I assume
> > inspired this.
>
> Wait, does someone install packages in the profile
> "~/.config/guix/current"? And does they install the package 'guix' in
> this profile? Nan...
Nah, the scenario is much less convoluted:
1. $PATH contains ~/.guix-profile/bin:~/.config/guix/current/bin, in
that order, as that is currently the default on a foreign distro.
2. User adds the guix package to their ~/.guix-profile. This doesn't
need to happen with 'guix package -i', in fact the IRC conversation that
inspired this [1] (though I seem to recall earlier occurrences of the
same problem) the user was making use of a manifest file. It might even
be easier to encounter this with a manifest file due to its clean-slate
nature.
3. ~/.guix-profile/bin/guix now takes priority. This means
- guix describe doesn't work
- guix pull has no effect
- guix package (-u or -m) will use an older 'guix' package than is
currently installed, as a packaged guix version doesn't contain the
package definition of itself, but the one that was previously
packaged.
I hope this helps resolve your confusion.
Regards,
Jakub Kądziołka
[1]: http://logs.guix.gnu.org/guix/2021-01-01.log#163217