Marius via <help-guix@gnu.org> writes:
> Good evening, Maxim
>
>
> I would like to see that diagram that you talked about in the last message
> (somehow the attachment did not get attached, or i did not recieve it on my
> end).
>
>
> So basically we have this workarounds in /etc/profile because in the case you
> install perl on system guix profile and xmlperlparser on your user guix
> profile, then some environment variables are not setup correctly, right?
>
>
> All roots to the fact that merging paths in /etc/profile works, but in
> ~/.bashrc (with guix --search-paths) does not?
Environment variables should not be set in rc files, set them in your
profile file (ie. .bash_profile). Guix will misbehave if you set them in
rc if you use pure shells.
Rutherther
>
> How is that? Because i'm comparing my merged paths in /etc/profile and in
> .bashrch and they give the same merged paths. The only difference is that
> .bashrc when calling guix package --search-paths adds additional env vars.
>
>
> My question is, is this workaround fixed in the current guix version (for
> what i've seen) but kept in /etc/profiles just to provide a backwards
> compatibility for when guix package --search-path did not exist?
>
>
> Because then I see this:
>
> ###########copied-from-20255bug thread#####
>
> --- a/etc/news.scm
> +++ b/etc/news.scm
> @@ -26,6 +26,39 @@
> (channel-news
> (version 0)
>
> + (entry (commit "2e888b4d07c67ad74fbb4ec9afb812a236852027")
> + (title
> + (en "@file{/etc/profile} changes require manual intervention"))
> + (body
> + (en "On Guix System, now the personal shell startup file
> +@file{~/.bash_profile} or @file{~/.zprofile} will be used to set up
> +environment variables for the user instead of @file{/etc/profile}. And
> +search-paths from multiple profiles are honored, which means a system
> +configured Xfce desktop environment can find its panel plugins in the user
> +profile.
> +
> +Before run @command{guix system reconfigure}, append the snippet below to
> each
> +user's @file{~/.bash_profile} or @file{~/.zprofile}:
> +
> +@example
> +# Merge search-paths from multiple profiles, the order matters.
> +eval \"$(guix package --search-paths \\
> +-p $HOME/.config/guix/current \\
> +-p $HOME/.guix-profile \\
> +-p /run/current-system/profile)\"
> +
> +# Prepend setuid programs.
> +export PATH=/run/setuid-programs:$PATH
> +
> +# Set up Guix Home profile
> +if [ -d ~/.guix-home ]; then . ~/.profile; fi
> +@end example
> +
> +Or you can override them with updated skeleton files after system
> reconfigure.
> +In addition, Guix Home users need to upgrade via @command{guix home
> +reconfigure}. See @uref{https://issues.guix.gnu.org/20255} for the
> +rationale.")))
> +
>
> ###########end-copied-from-20255bug thread#######
>
>
>
> I feel like this problem has already been patched with the addition of the
> home profile definition that merges paths. But it only lasts to remove the
> old workaround from /etc/profile, right?
>
> In conclusion, are we dealing with a case were the fix was applied but the
> old workaround wasn't removed? I mean, users were even told by news that
> /etc/profile may not merge paths anymore. But the code still remains there.
> If that's the case, then what's left is to remove the old workaround from
> /etc/profile.
>
>
> You basically opened the bug back because there was still remaining
> workaround code inside /etc/profile, right?
>
>
> For now I'm just learning Guix and observing but if what is left to do in
> order to close that bug for good is to remove the old workaround, then I can
> do it myself when I get more confident.
>
>
>
> --
> Thanks,
> Marius
