On Fri, Dec 29, 2023 at 6:43 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote:
> On Thu, Dec 28, 2023 at 05:07:09PM +0000, Barry Scott wrote: > > > > > > > On 28 Dec 2023, at 16:58, Chris Adams <li...@cmadams.net> wrote: > > > > > > Anything that depends on PATH entries is IMHO doomed to failure. > > > There are way too many things that explicitly set PATH to "known" > > > values (for good and bad reasons) to be able to depend on > > > extending it. Heck, it took a long time to get sudo just to > > > include /usr/local/{bin,sbin}. > > Things that reset $PATH to "known" values are usually breaking things > and doing unnecessary work. It is OK to extend the $PATH by inserting > something (usually at the front), but systemd sets it to something > appropriate on a given system for _everything_ that is started, so > resetting it is not useful. > > It was very common to set the $PATH via .bash_profile or other > shell-specific mechanisms. This is flexible and convenient, but the > problem with that approach is that it happens too late: since now the > system may get all the way the graphical interface without going > through a shell, if we want $PATH to be set properly for the whole > environment including service binaries started directly by systemd, > this needs to be done by systemd itself. And once it has done that, > it's not helpful if the shell also plays with $PATH, affecting some > processes but not others. > > But yeah, it's possible that sometimes we'll and up with an environment > with $PATH without the additional directories. That's OK: it will > gracefully fall back to the generic versions. Hopefully, people > will fix those environments over time. > > (Sudo is a special case: it needs to reset the path to avoid being > influenced by the calling environment. But things started through sudo > are generally not CPU-intenstive, so using the generic versions should > be OK.) > > > Indeed, how would my shell get the right micro architecture into its > PATH? > > Would konsole on plasma desktop picking up PATH from systemd? > > Yes. If should already be doing that. > > > The alternative would be to symlink the "right" version of a > program/library from > > the micro architecture dir into /usr/bin and /usr/lib maybe? > > The approaches with glibc-hwcaps and the proposed path-based thing for > binaries > have the advantage that they are dynamic. The same image can be used on > different > machines. It may even be read-only. In particular, in case of VMs, if we > stop > the VM, move it to a different host or change it's CPU settings, and > restart it, > it'll gracefully DTRT. It also important that the system remains functional > even if a CPU downgrade happens for any reason. > > We _could_ take the approach with symlinks. Most likely, this would be > handled > via alternatives, i.e. the symlinks would go through /etc, i.e. > /usr/bin/foo > → /etc/alternatives/foo → /usr/lib-something/bin/foo. This is doable, but I > like the dynamic approach much more. > > Also, glibc-hwcaps are implemented and available since glibc 2.33. > Combining a static symlink-based system for binaries with a dynamic > path-based system for libraries would be very strange. > > On a philosophical note, I once worked on Apollo workstations. These could switch behavior between sysv and bsd unix. To do this, the kernel would interpret e.g. /usr/bin/$arch, substituting the env variable arch. At least that is my recollection of how this worked. Elegant I think, but some might see this as a security problem.
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue