bug#30093: Installing python-ipython breaks Gnome on Fedora.

[Chris Marusich]

Fis Trivial <address@hidden> writes:

> Maybe we can Maybe we can divide those environment variables into two types:
>       1. Needed directly by human. For example the *PATH* environment, we use 
> it
>                to start whatever program from the shell.
>       2. Environment variables only needed by programs. For examples, the
>        *PYTHONPATH*, or in this case *GI_TYPELIB_PATH*.
>
> For _type 2_, we can try to wrap every program with a simple script, and
> propagate all the needed environment variables from its dependencies to that
> wrapping script. This should eliminate the need to put any of those 
> environment
> variables into ~/.guix-profile/etc/profile, guaranteeing the safety of these
> variables.
>
> But this method won't solve all the problems. For examples *XDG_DATA_DIRS* 
> will
>  be classified as one of variables that needed by human because we need to use
>  it to find GUI programs with GUI shell, and it's also needed by some programs
> (a script in this case):

I'm not sure this will help.  As you just pointed out, the
classification doesn't really match reality, which limits its
usefulness.

>> This sounds similar to the following bug:
>>
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26202
>>
> To mitigate the problem in above link, which is the problem introduced by
> _type 1_ variables, maybe we can treat these environment variables 
> differently.
> When guix is updating it to a new value due to change of profile, it should
> explicitly append the original value to the upgraded definition (explicitly
> means writing it down in expanded form, like "/home/fis/.bin", not $HOME/.bin 
> or
> $VARIABLE_NAME). In the above bug, there is no way guix can define the
> *XDG_DATA_DIRS* earlier than the distro. (You have to run the distro then
>  install guix, right?). It's not perfect, but it seems to work.

It sounds like you're suggesting that when Guix builds the new profile,
it should take into consideration current value of the user's
environment variables when building the profile.  This is not
permissible in the purely functional software deployment model that Guix
follows.  The work-around suggested in Bug 26202 is a specific, "impure"
work-around for a specific problem on a specific foreign distribution,
which requires a user to modify their environment outside the scope of
Guix's purely functional model.  In general, for any given foreign
distribution, there may be other problems that occur because the
environment variables set by Guix are not formed or used in precisely
the way that the foreign distribution expects.  These problems may
require changes that are, in general, impossible for Guix to predict or
(if the solution requires changes that depend impurely on the
environment) impossible for Guix to make without violating the purely
functional model.

I suspect that this class of problem won't be easy to fix generically
from within Guix.  Instead, I suspect it's more realistic to look for
solutions on a case-by-case basis.  For example, the work-around for Bug
26202 is currently a reasonable solution for that particular issue on
that particular foreign distribution.  Even if we might be able to solve
a particular problem like that one by introducing impurities into the
build, I'm not convinced it would fix this class of problems in general.
In any case, I'm afraid that the fact that it would require us to
introduce impurities into the build probably makes it a non-starter for
the reasons I mentioned above.

Of course, if there is a way to solve this class of problem more
generally without introducing impurities, that'd be great.  I just can't
think of one at this time.

-- 
Chris

signature.asc
Description: PGP signature