On Wed, Apr 03, 2024 at 01:43:14PM +0000, Laurent Bercot wrote:
> > There have been some discussions, starting at Fedora, about unifying
> > the bin and sbin directories:
> > https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin
>
> Ha. 25 years later, they understand that the separation makes no sense,
> and *just* when we were going to use that silly separation to work around
> an even sillier idiosyncrasy.
>
> Talk about timing.
>
>
> > Also, even apart from unifying the directories, there are various
> > people who have expressed concern about having different programs with
> > the same name in /usr/bin and /usr/sbin, thus making it something of
> > a potluck which one will be invoked depending on the user's search path.
> > I have to admit that I am kind of in agreement with that: different
> > binaries with the same name in directories that are both meant to be in
> > the search path seems... a bit fishy to me, and, yeah, with
> > the potential for problems if the directories are reordered
> > (I have seen arguments for both sides: "things in /sbin are more
> > important, so it should come before /bin; things in /bin are used
> > much more often, so it should come before /sbin").
>
> I agree with all this. In principle, /usr/bin and /usr/sbin should not be
> distinct, for all these reasons.
> The thing is, we're not in the realm of "good design", here. We're in the
> realm of "work around the braindeadness and use the cracks to uglyhack
> something that works".
>
> If rpm doesn't have an alternatives system to get the useless binaries out
> of the way, and if /usr/sbin is unusable, then there's nothing left but
> "add another directory to the global PATH", which is super invasive.
FWIW, my comments were more like general observations, not really
constructive suggestions, since yeah, I do understand the problem
(there are many things I like about the POSIX standard, but this
particular one that has led to the presence of a cd "executable" on
other Unix-like systems, too, I have really, really, really
never understood; I have seen (and sometimes tried to answer without
going off into a helpless rage) user questions about that for
several different OS's).
So, yeah, I just thought I'd bring that up as a possible problem
down the road... and yes, alternatives do sound like a possible
way forward, if:
- the maintainers of the other packages agree to use them
- the maintainers of the other packages agree that execline's "cd"
ought by default to have a higher priority
- there are not too many "hey, I KNOW what I'm doing!" people who
decide to manually set bash's cd as the one and only way :/
(hopefully there really won't be many of those)
Also, thanks for all your work on execline, s6, and friends, and
for your perseverance when that work turns into suchlike bouts of
helpless rage!
G'luck,
Peter
--
Peter Pentchev roam_at_ringlet.net roam_at_debian.org pp_at_storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Received on Thu Apr 04 2024 - 08:13:23 CEST