On Sun, 10 Feb 2013, Quentin Glidic wrote: > On 09/02/2013 23:46, Saleem Abdulrasool wrote: > > /sbin is meant for system binaries that are needed for system > > administration only. Any non-critical (i.e. not required for system > > boot or recovery) system administration binaries should go to > > /usr/sbin. > > > > If you feel like there are binaries which reside in /sbin or > > /usr/sbin currently and should be moved into /bin or /usr/bin please > > start a thread on that separately. > > > > What you are proposing strictly violates the FHS. It explicitly > > states that /sbin and /usr/sbin are to be included in PATH for the > > root user *only*. If you wish to ignore this recommendation from > > the FHS, please state this clearly, and ideally, provide some > > justification. Effectively, what you are proposing would merge /bin > > and /sbin, /usr/bin and /usr/sbin. It seems that the more efficient > > way to do this would be to just do that -- merge them and delete > > /sbin and /usr/sbin. > > I do. > > > While "every exherbo user is highly likely to be a super user" is > > very much an expectation, I don't think that warrants merging system > > administration binaries into the usual day-to-day environment. System > > administration is not the primary use of the system in most cases. > > I think arguments a) to g) (e) being for zsh because we already have > ROOTPATH in PATH for our default zprofile) of this email (please don’t > troll the author…) are pretty relevant: > https://lists.fedoraproject.org/pipermail/devel/2011-October/158845.html
The server seems to be inaccessible, at least for the moment. > > > Parsing random scripts seems extremely fragile to me. Why not fix > > the DM to properly handle environment setup instead? This seems > > like a much cleaner solution to me. The DM is less likely to break > > in the future if the syntax changes while being able to take > > advantage of improvements in newer versions of the interpreter. > > DM just run a session script (sh most of the time) which sources > ~/.profile or even ~/.xprofile. These scripts are often (always?) > distro-specific. If they are able to simply source the scripts, it implies that they have launched a shell, which should setup the environment as appropriate. I dont see why you brought up the point of DM interactions at all then. > > > PAM is not an absolute requirement for a working system and not all > > tools are PAM enabled (e.g. chroot and a number of tools from > > coreutils). With your proposal, you have introduced a mandatory > > usage of PAM for everyone, and potentially on programs which do not > > currently support PAM. > > PAM is enabled for login, su, XDM, GDM, LightDM, SLiM and LXDM. OpenSSH, > Dropbear and sudo have a pam option (some others too, but they are not > involved here). These options could be killed, unless there is a > specific use case where one would like to avoid PAM (I don’t know all > SSH usages), because PAM is in system (trough util-linux and shadow at > least). > Every login entry point are PAM-enabled. And we can always keep > profile.env for corner cases. As far as GDM, yes, PAM is not "enabled" for GDM, it is a strict requirement for it. That said, I use system configurations with and without PAM though. There is no reason to drop those options. > chroot is a corner case, because it does not change the environment nor > it launches a login shell. Since we do not source profile.env in our > default bashrc, the environment is not modified at all when chrooting > Exherbo, and the install guide asks to source /etc/profile. We can just > change that to profile.env. I use chroot with a login shell quite often. So, yes, it does change the environment, and it does launch a login shell. > > One issue with the use of pam_env for this purpose is that you now > > need to restart your session to get an environment change as > > restarting your shell is no longer sufficient to get the changes to > > /etc/environment. > > In case of login shells, you already have to restart the whole session. You can manually launch a login shell without creating a new session. > In case of non-login interactive shells, the default bashrc does not > source the profile.env, the default zshrc does. Again, we can keep > profile.env around for these cases (the user can either add the source > in her ~/.bashrc or source manually after an update). If the issue is really that /etc/bashrc does not source /etc/profile.env, why not just change that? > In case of non-shells (X sessions), you still have to restart the > session. An example is when you install a new Firefox plugin, it may > need to update MOZ_PLUGIN_PATH variable. gnome-session and others might > provide an interface to update the environment at runtime but that’s > another debate. The point is that you do not currently need to restart the session, you can simply spawn a new shell. > Also, to update the existing shell environment variables, sourcing > /etc/environment is enough. > > > Evaluating a few variables is not that expensive on modern machines. > > We can still cleanup the environment setup and optimise the variable > > setting to avoid re-calculating values if that is an issue. > > Not an issue, just a little bonus. But one can want Exherbo on some slow > hardware (using pbins maybe, and cross is going to make that really easier). > > > > What about expected shell behaviour of login vs non-login shells > > (environment sourcing is supposed to be different across the two). > > Yes, non-login shells are not supposed to modify the environment, unless > explicit user action (tweak the ~/.bashrc or execute commands). > > > -- > > Quentin “Sardem FF7” Glidic _______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
