Hi Marius, Marius <[email protected]> writes:
> Hi Maxim, > > Thank you for the fast response. > > I did not understand much the original problem tbh (2015). As I said > before I'm not a Guix expert so I may be just lost. > > For what I can see from the modern discussion of the bug (2022-2023) > this is non-guix-approach configuration is kept like this just because > old GuixSD required that?: > > CITE: > > "Josselin Poiret <dev <at> jpoiret.xyz> writes: > >> Hi Maxim, >> >> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes: >> >>> Just to make sure, remove what exactly? >> >> Remove the bit in /etc/profile that loads the user's profile, if it is >> indeed supposed to be loaded by the user's own ~/.zprofile or >> ~/.bash_profile. > > Remove will break existed systems, so need a NEWS entry as Maxim > mentioned, and maybe some explainations and examples in the manual > about how to setup the environments as needed. > > I could make a patch for it this weekend if no one beats me.. I'd be a bit wary of applying any patches touching /etc/profile, as the shell loading logic is always a bit of a maze and I need to relearn how it works every time, and it's hard to test all cases. Here's a diagram I keep around, which doesn't represent all the non-default cases enabled in the Guix-provided Bash (it honors /etc/bashrc, and it always sources ~/.bashrc over SSH). <#part type="image/png" buffer=BashStartupFiles1.png disposition=attachment> <#/part> At a minimum, the `make check-system TESTS=basic` should still pass. Other uses cases to consider: offloading and guix deploy (which uses SSH and must be able to use Guix on the remote). >> At least, I don't know if there is a general agreement > >> on what should be done in /etc/profile vs. the user's own config. > > I think hopefully we can agree that /etc/profile only handle the > system profile, and user's own config can decide what it want. Most of the things there are workaround for bugs (such as the merging of the system profile and user profile variables for the user linked above -- bug#20255, but also bug#22138 which means that a user would need to install gstreamer to their user profile to pull in the gstreamer search paths used for locating the gstreamer plugins). Unless these long standing bugs are finally fixed, it seems ill advised to remove the workarounds kept in /etc/profile, but I agree about the direction. > Despite mitigation, it still work out of the box with skeletons, and > user can arrange priorities among profiles, or disable the system one. > > Or configure it via home-shell-profile (TODO: need some changes)." > > END OF CITE. > > I'm not a Guix developer (yet. I don't feel confident), but I agree > with the fact that no user env variables should be called or setup in > /etc/profile. In the Guix spirit doesn't make sense, but even without > considering that it also does not make sense in the shell spirit, > because that's why there is the .bash_profile (or equivalent). > > > Still I don't get why /etc/profile has to contain any user profile env var > definition. > > For example let's say the variable INFOPATH: > > My /etc/profile defines: 'export > INFOPATH=$HOME/.guix-profile/share/info:/run/current-system/profile/share/info' > > And my ~/.bash_profile performs: > > eval "$(guix package --search-paths -p $HOME/.config/guix/current -p > $HOME/.guix-profile ......)" > > guix package --search-paths.... eventualy will do "export > INFOPATH=$HOME/.guix-profile/share/info:$INFOPATH" (or equivalently > pointing to the gnu/store/....profile/share/info of my user). Perhaps that particular one could be simplified, but note that the skeletons are at no point refreshed past the initial 'guix system init', so many users are likely to miss them (and removing the equivalent snippets from /etc/profile could break something on their system). [...] > What is the case that runs a login shell that does not read > bash_profile and still needs user env var defined? If that's even > possible. The case of an older init'd Guix System machine that doesn't include the eval --search-paths introduced in 40310efde9b4a4f2cf98081d6cd10f843685ebb6 (2023) could be one, I think. > I just don't see the conditions required in which /etc/profile is > loaded but bash_profile no. And even if that was possible does that > make any sense? > > That could only happen if there where no users some how, but then why > would you want to define user env var anyways? > > > And for me it breaks all the Guix philosophy. At the end guix is > transactional by modifying each profile environment to a point in > time. But if my user profile boots with environment variables defined > for his environment that are setup before his existence then that's > contradictory with the fact that each profile can travel in time by > changing its own environment. > > The profile own governance of its instance should be only be performed > by himself not by a prior system wide configuration. I think there's inevitably some coupling between the system and the user profiles; such as via PATH and the likes. Even the libc used by the system can cause malfunction of the user profile, such as by lagging behind the libc the user profile applications were linked against (breaking things like locales -- which is probably a bug we should look into). If you want more isolation working from 'guix shell --pure' or even 'guix shell --container' is the way to go. -- Thanks, Maxim
