Hello, Alex Kost <[email protected]> writes:
> zimoun (2020-02-21 16:53 +0100) wrote: > >> Dear, >> >> What is the status of the bug#20255 [1]? >> It is old; the last activity seems back on 2015, November. So let resume. >> >> The issue is, e.g.: >> - perl installed into the system profile >> - perl-xml-parser installed into an user profile >> Then "guix package --search-paths" does not set correctly XML::Parser. >> >> >> Fixes had been pushed: dedb17a and b2a7223 and cc3de1d. >> >> The final fix is still missing. Because it is a controversial patch >> [2] :-) i.e., running 'guix' in '/etc/profile'; see these lines of the >> patch: >> >> + eval `/run/current-system/profile/bin/guix package \\ >> + -p /run/current-system/profile \\ >> + -p \"$HOME/.guix-profile\" --search-paths` >> >> >> The friendly "protest" [3] is about turning these lines optional via >> an environment variable. I am not sure to follow where the discussion >> had been going then. > > As for me, I am OK with any default setting as long as there is a way to > change it. I recall Ludovic proposed a patch that allowed to customize > "/etc/profile" and I was happy about it, but he changed his mind on that > patch so it was never committed. Do you still have a vetted interest in the issue at hand? This is a serious usability problem that's been in limbo for 6 years, apparently for reasons of purity (not wanting to run a command in /etc/profile). While I share the sentiment that /etc/profile would better be 'inert' or static, it seems we haven't been able to come up with a better solution than calling 'guix package --search-paths'. Like Ludovic, I also don't find the idea of allowing users to override /etc/profile very appealing; even if undocumented, its mere presence in the operating-system field would be an invitation for problems. An environment variable to disable such basic functionality also seems backward to me. I would personally be in favor of committing the fix as-is. If < 1 s of wasted time on boot is an issue, I suggest to look into GNU Shepherd to offset it; optimization opportunities should abound :-). Thank you, Maxim
