On Fri, Dec 29, 2023 at 6:43 AM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote:
On Thu, Dec 28, 2023 at 05:07:09PM +0000, Barry Scott wrote:
>
>
> > On 28 Dec 2023, at 16:58, Chris Adams <linux@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
