From: Fis Trivial <ybbs.daans@hotmail.com>
To: Chris Marusich <cmmarusich@gmail.com>
Cc: "30093@debbugs.gnu.org" <30093@debbugs.gnu.org>
Subject: bug#30093: Installing python-ipython breaks Gnome on Fedora.
Date: Sun, 14 Jan 2018 18:31:26 +0000 [thread overview]
Message-ID: <MWHPR16MB006339CA06E01E82683F357092150@MWHPR16MB0063.namprd16.prod.outlook.com> (raw)
In-Reply-To: <871sitcm4j.fsf@gmail.com>
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):
> 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.
I don't have any better idea for now. Does anybody know what kind of approaches
are employed by Flatpak and Snap?
next prev parent reply other threads:[~2018-01-14 18:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-12 21:32 bug#30093: Installing python-ipython breaks Gnome on Fedora Fis Trivial
2018-01-13 21:39 ` Fis Trivial
2018-01-14 0:36 ` Chris Marusich
2018-01-14 18:31 ` Fis Trivial [this message]
2018-01-14 19:01 ` Fis Trivial
2018-01-14 22:25 ` Chris Marusich
2018-01-15 0:45 ` Chris Marusich
2018-01-17 19:53 ` Fis Trivial
2020-10-04 18:25 ` Maxim Cournoyer
2021-05-19 16:14 ` bug#30093: what manual workaround? tomas.almeida
2021-05-24 0:16 ` Carlo Zancanaro
2021-05-24 10:30 ` tomas.almeida
2022-09-29 2:50 ` bug#30093: Installing python-ipython breaks Gnome on Fedora Maxim Cournoyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=MWHPR16MB006339CA06E01E82683F357092150@MWHPR16MB0063.namprd16.prod.outlook.com \
--to=ybbs.daans@hotmail.com \
--cc=30093@debbugs.gnu.org \
--cc=cmmarusich@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.