On Tue, Oct 15, 2019 at 11:08:14PM -0400, Joshua Kinard wrote:
> On 10/15/2019 13:34, David Seifert wrote:
> > On Tue, 2019-10-15 at 12:04 -0400, Mike Gilbert wrote:
> >> On Tue, Oct 15, 2019 at 12:02 PM Mike Gilbert <flop...@gentoo.org>
> >> wrote:
> >>> On Tue, Oct 15, 2019 at 8:00 AM David Seifert <s...@gentoo.org>
> >>> wrote:
> >>>> On Sun, 2019-10-13 at 12:33 -0400, Mike Gilbert wrote:
> >>>>> On Sat, Oct 12, 2019 at 1:52 PM David Seifert <s...@gentoo.org>
> >>>>> wrote:
> >>>>>> On Sat, 2019-10-12 at 19:01 +0200, Dennis Schridde wrote:
> >>>>>>> On Samstag, 12. Oktober 2019 18:02:28 CEST William Hubbs
> >>>>>>> wrote:
> >>>>>>>> On Sat, Oct 12, 2019 at 01:11:49PM +0200, Michał Górny
> >>>>>>>> wrote:
> >>>>>>>>> On Sat, 2019-10-12 at 13:00 +0200, David Seifert wrote:
> >>>>>>>>>> * Some distros have not just merged / and /usr, they
> >>>>>>>>>>
> >>>>>>>>>>   have also merged /usr/bin and /usr/sbin. By giving
> >>>>>>>>>>   users the choice of merging */bin and */sbin,
> >>>>>>>>>>   Gentoo follows suit.
> >>>>>>>>>
> >>>>>>>>> What about the scenario when /bin has been merged with
> >>>>>>>>> /usr/sbin
> >>>>>>>>> and /sbin with /usr/bin?  ;-P
> >>>>>>>>
> >>>>>>>> I also don't see the need for something like this. The
> >>>>>>>> idea of
> >>>>>>>> the
> >>>>>>>> /usr
> >>>>>>>> merge is to have all binaries available in one place, and
> >>>>>>>> there
> >>>>>>>> really
> >>>>>>>> is not a good justification for separating bin from sbin.
> >>>>>>>
> >>>>>>> Do I read this correctly?  USE=-split-usr currently means
> >>>>>>> that
> >>>>>>> /bin,
> >>>>>>> /sbin, /
> >>>>>>> usr/bin and /usr/sbin point to the same directory?
> >>>>>>>
> >>>>>>> If that is not the case, then I agree that users should
> >>>>>>> have the
> >>>>>>> possibility
> >>>>>>> to set it up like this and USE=-split-sbin should be
> >>>>>>> supported.
> >>>>>>>
> >>>>>>> --Dennis
> >>>>>>
> >>>>>> I agree, I wasn't aware that USE=-split-usr implies the
> >>>>>> complete 2-
> >>>>>> level (/usr and *sbin) merge. In that case, all of this is
> >>>>>> obsolete.
> >>>>>
> >>>>> That was NOT my intention when I introduced the split-usr USE
> >>>>> flag.
> >>>>>
> >>>>> For bin/sbin, I would prefer to drop any conflicting links
> >>>>> unconditionally. Do you have examples of scenarios where this
> >>>>> is not
> >>>>> possible?
> >>>>>
> >>>>
> >>>> William has confirmed on IRC that USE=-split-usr performs the
> >>>> complete
> >>>> Fedora-esque /usr merge (which makes sense IMO).
> >>>
> >>> William's opinion is not the only one that matters.
> >>
> >> Sorry, I guess you are referring to the behavior baselayout? That
> >> doesn't necessarily align with the global usage.
> >>
> > 
> > https://gitweb.gentoo.org/proj/baselayout.git/tree/Makefile#n93
> > 
> > Clearly the usr-merge in baselayout intends to merge all these 4
> > directories. There is currently no option to merge /usr and / but keep
> > /bin and /sbin separate, so the most parsimonious solution here is to
> > assume that usr-merge semantics in Gentoo is about merging all 4
> > directories.
> 
> What is the source or origin point of the desire to merge /sbin into /bin?
> I know Fedora/RedHat championed the /usr/[s]bin into /[s]bin bit, but this
> is the first I've heard of trying to put all executables in one spot.  I
> have my doubts about such an idea, but want to see what the rationale is
> this time before writing the idea off to the funny farm.
> 
> My understanding for the separation was system binaries that only the
> superuser needs to touch go into /sbin and everything else into /bin.  This
> allowed for unpriv user PATHs to exclude /sbin (and in times antiquity, also
> exclude /usr/sbin).

Back in the day, the s in /sbin and /usr/sbin meant static, not super
user. All binaries in those directories were statically linked.

https://www.osnews.com/story/25556/understanding-the-bin-sbin-usrbin-usrsbin-split/
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

The tl;dr is that the meaning of /sbin and /usr/sbin was lost years ago.

William

Attachment: signature.asc
Description: Digital signature

Reply via email to