[gentoo-dev] newsitem: baselayout 2.5 changes

[gentoo-dev] newsitem: baselayout 2.5 changes

[William Hubbs]

[-- Attachment #1.1: Type: text/plain, Size: 154 bytes --]

All,

here is a proposed newsitem for baselayout 2.5.

Let me know what you think, including whether these are newsitem-worthy
or not.

Thanks,

William


[-- Attachment #1.2: 2018-02-xx-baselayout-25-changes.en.txt --]
[-- Type: text/plain, Size: 1026 bytes --]

Title: baselayout 2.5 updates
Author: William Hubbs <williamh@gentoo.org>
Posted: 2018-02-xx
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: <sys-apps/baselayout-2.5

There are three significant changes in baselayout-2.5.

The first change is that ROOTPATH is no longer set. This means all of
the *sbin directories will be added to the default path for all users
instead of just the root user. I know of no packages outside of
baselayout that used the ROOTPATH variable; however, if packages
do use it, they will need to be adjusted to use PATH instead.

The second change is that baselayout is taking ownership of most of the
directories it creates. This includes all directories in / and /usr
excluding /lib* and /usr/lib*. Once we drop support for SYMLINK_LIB,
baselayout will take ownership of /lib* and /usr/lib* as well.

Third is the beginning of support for the /usr merge through the
addition of the usrmerge use flag.
DO NOT, DO NOT TURN THIS ON UNLESS YOU KNOW WHAT YOU ARE DOING AND CAN
HELP WITH TESTING.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[Mike Gilbert]

On Thu, Feb 8, 2018 at 2:52 PM, William Hubbs <williamh@gentoo.org> wrote:
> All,
>
> here is a proposed newsitem for baselayout 2.5.
>
> Let me know what you think, including whether these are newsitem-worthy
> or not.

Eliminating ROOTPATH seems like a significant change. Was this
officially discussed somewhere that I missed?

I actually support the change, but other people should be given the
chance to complain about it on the record.

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

>>>>> On Thu, 8 Feb 2018, Mike Gilbert wrote:

> Eliminating ROOTPATH seems like a significant change. Was this
> officially discussed somewhere that I missed?

> I actually support the change, but other people should be given the
> chance to complain about it on the record.

It contradicts the FHS, which says that /sbin contains "root-only
commands" and that "ordinary users should not have to place any of the
sbin directories in their path." [1]

Ulrich


[1] http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s16.html#ftn.idm236092603392

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[Mike Gilbert]

On Thu, Feb 8, 2018 at 3:41 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Thu, 8 Feb 2018, Mike Gilbert wrote:
>
>> Eliminating ROOTPATH seems like a significant change. Was this
>> officially discussed somewhere that I missed?
>
>> I actually support the change, but other people should be given the
>> chance to complain about it on the record.
>
> It contradicts the FHS, which says that /sbin contains "root-only
> commands" and that "ordinary users should not have to place any of the
> sbin directories in their path." [1]

That would be fine if we actually followed the recommendation
mentioned in the first half of that footnote.

"Deciding what things go into "sbin" directories is simple: if a
normal (not a system administrator) user will ever run it directly,
then it must be placed in one of the "bin" directories."

However, there are plenty of examples of commands that normal users
may run from sbin. Moving these commands often causes problems for
packages that either hard code absolute paths, or detect paths at
build time. I think it would be less disruptive to add sbin to PATH
than it would be to try and "fix" all the packages that install
commands in the wrong place.

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1607 bytes --]

On Thu, Feb 08, 2018 at 03:55:02PM -0500, Mike Gilbert wrote:
> On Thu, Feb 8, 2018 at 3:41 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>>> On Thu, 8 Feb 2018, Mike Gilbert wrote:
> >
> >> Eliminating ROOTPATH seems like a significant change. Was this
> >> officially discussed somewhere that I missed?
> >
> >> I actually support the change, but other people should be given the
> >> chance to complain about it on the record.

It has been a long time, but I believe I brought it up at some point in
the past. I'll look for a link in a few and reply with it if I find it.

> > It contradicts the FHS, which says that /sbin contains "root-only
> > commands" and that "ordinary users should not have to place any of the
> > sbin directories in their path." [1]
> 
> That would be fine if we actually followed the recommendation
> mentioned in the first half of that footnote.
> 
> "Deciding what things go into "sbin" directories is simple: if a
> normal (not a system administrator) user will ever run it directly,
> then it must be placed in one of the "bin" directories."
> 
> However, there are plenty of examples of commands that normal users
> may run from sbin. Moving these commands often causes problems for
> packages that either hard code absolute paths, or detect paths at
> build time. I think it would be less disruptive to add sbin to PATH
> than it would be to try and "fix" all the packages that install
> commands in the wrong place.

There are no reasons to remove the *sbin directories from PATH; I know
of no other distros that do this.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 867 bytes --]



On 08/02/18 22:13, William Hubbs wrote:
> On Thu, Feb 08, 2018 at 03:55:02PM -0500, Mike Gilbert wrote:
>> However, there are plenty of examples of commands that normal users
>> may run from sbin. Moving these commands often causes problems for
>> packages that either hard code absolute paths, or detect paths at
>> build time. I think it would be less disruptive to add sbin to PATH
>> than it would be to try and "fix" all the packages that install
>> commands in the wrong place.
> There are no reasons to remove the *sbin directories from PATH; I know
> of no other distros that do this.
>
> William
>
Pardon my ignorance, but does that mean you are essentially relying on
file system features/permissions and security settings to enforce
correct use of system tools?! Or is this just to make sudo/etc commands
'more convenient' ?!

MJE


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[Michael Orlitzky]

On 02/08/2018 05:13 PM, William Hubbs wrote:
> 
> There are no reasons to remove the *sbin directories from PATH; I know
> of no other distros that do this.

The first reason that comes to mind is that when I type something like
p<tab> to remind me of a command name, I don't need to see 50 programs
that I'm not allowed to run in the list.

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[Rich Freeman]

On Thu, Feb 8, 2018 at 5:17 PM, M. J. Everitt <m.j.everitt@iee.org> wrote:
>
>
> On 08/02/18 22:13, William Hubbs wrote:
>> On Thu, Feb 08, 2018 at 03:55:02PM -0500, Mike Gilbert wrote:
>>> However, there are plenty of examples of commands that normal users
>>> may run from sbin. Moving these commands often causes problems for
>>> packages that either hard code absolute paths, or detect paths at
>>> build time. I think it would be less disruptive to add sbin to PATH
>>> than it would be to try and "fix" all the packages that install
>>> commands in the wrong place.
>> There are no reasons to remove the *sbin directories from PATH; I know
>> of no other distros that do this.
>>
>> William
>>
> Pardon my ignorance, but does that mean you are essentially relying on
> file system features/permissions and security settings to enforce
> correct use of system tools?! Or is this just to make sudo/etc commands
> 'more convenient' ?!

If you're depending on binaries not being in the PATH for security,
you're doing it wrong.  If you're depending on filesystem
features/permissions (other than the SUID bit or POSIX capability
settings) for security when it comes to performing privileged
operations, you're also doing it wrong.

There are actually quite a few binaries in /sbin and /usr/sbin which
can be useful for non-root users.  Sure, we could go through there
carefully and move stuff to /bin but honestly doing what everybody
else does and just sticking /sbin in the default path makes more
sense.

If you're typing p<tab> to find a command then adding an extra ~20
commands to the ~850 that are listed on my system isn't going to break
the bank.

-- 
Rich

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]

All,

here is a link to an old, but brief discussion about this.

https://archives.gentoo.org/gentoo-dev/message/2fc1f62c7cf225787fe52f4dace7368c

I think we have talked about this several other times, but not done
anything about it.

On Thu, Feb 08, 2018 at 10:17:59PM +0000, M. J. Everitt wrote:
> 
> 
> On 08/02/18 22:13, William Hubbs wrote:
> > On Thu, Feb 08, 2018 at 03:55:02PM -0500, Mike Gilbert wrote:
> >> However, there are plenty of examples of commands that normal users
> >> may run from sbin. Moving these commands often causes problems for
> >> packages that either hard code absolute paths, or detect paths at
> >> build time. I think it would be less disruptive to add sbin to PATH
> >> than it would be to try and "fix" all the packages that install
> >> commands in the wrong place.
> > There are no reasons to remove the *sbin directories from PATH; I know
> > of no other distros that do this.
> >
> > William
> >
> Pardon my ignorance, but does that mean you are essentially relying on
> file system features/permissions and security settings to enforce
> correct use of system tools?! Or is this just to make sudo/etc commands
> 'more convenient' ?!

The basic problem is that what goes in *bin vs *sbin is quite arbitrary
and the best way to fix it is to make all of the *bin and *sbin
directories accessible to all users.

You can't rely on a path to separate system-only programs from
programs that users might want to run, and some programs can be run by
users to look around but not change things.

Here is one non-gentoo source discussing this.

http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

Even if we don't adopt the usr merge in Gentoo Linux as default, removing *sbin
from the path doesn't make sense.

William

> 
> MJE
> 




[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 2013 bytes --]

On 08/02/18 22:33, William Hubbs wrote:
> All,
>
> here is a link to an old, but brief discussion about this.
>
> https://archives.gentoo.org/gentoo-dev/message/2fc1f62c7cf225787fe52f4dace7368c
>
> I think we have talked about this several other times, but not done
> anything about it.
>
> On Thu, Feb 08, 2018 at 10:17:59PM +0000, M. J. Everitt wrote:
>>
>> On 08/02/18 22:13, William Hubbs wrote:
>>> On Thu, Feb 08, 2018 at 03:55:02PM -0500, Mike Gilbert wrote:
>>>> However, there are plenty of examples of commands that normal users
>>>> may run from sbin. Moving these commands often causes problems for
>>>> packages that either hard code absolute paths, or detect paths at
>>>> build time. I think it would be less disruptive to add sbin to PATH
>>>> than it would be to try and "fix" all the packages that install
>>>> commands in the wrong place.
>>> There are no reasons to remove the *sbin directories from PATH; I know
>>> of no other distros that do this.
>>>
>>> William
>>>
>> Pardon my ignorance, but does that mean you are essentially relying on
>> file system features/permissions and security settings to enforce
>> correct use of system tools?! Or is this just to make sudo/etc commands
>> 'more convenient' ?!
> The basic problem is that what goes in *bin vs *sbin is quite arbitrary
> and the best way to fix it is to make all of the *bin and *sbin
> directories accessible to all users.
>
> You can't rely on a path to separate system-only programs from
> programs that users might want to run, and some programs can be run by
> users to look around but not change things.
>
> Here is one non-gentoo source discussing this.
>
> http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
>
> Even if we don't adopt the usr merge in Gentoo Linux as default, removing *sbin
> from the path doesn't make sense.
>
> William
>
Thank you William, and also rich for your explanations! I do see where
you're coming from now.

Michael.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[Michael Orlitzky]

On 02/08/2018 05:33 PM, Rich Freeman wrote:
> 
> There are actually quite a few binaries in /sbin and /usr/sbin which
> can be useful for non-root users.  Sure, we could go through there
> carefully and move stuff to /bin but honestly doing what everybody
> else does and just sticking /sbin in the default path makes more
> sense.

Yeah hiding the bug is easier than fixing it, but has the downside that
the bug doesn't get fixed.

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

On Thu, Feb 08, 2018 at 05:49:52PM -0500, Michael Orlitzky wrote:
> On 02/08/2018 05:33 PM, Rich Freeman wrote:
> > 
> > There are actually quite a few binaries in /sbin and /usr/sbin which
> > can be useful for non-root users.  Sure, we could go through there
> > carefully and move stuff to /bin but honestly doing what everybody
> > else does and just sticking /sbin in the default path makes more
> > sense.
> 
> Yeah hiding the bug is easier than fixing it, but has the downside that
> the bug doesn't get fixed.

There is no bug here. The problem, as I said before in this thread, is
that what goes in *sbin is arbitrary, and as Rich said, if you are
relying on the path to prevent a non-root user from running something
that only root should run, you are doing it wrong. All the user has to
do is type a full path to a command and it will be run.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[Michael Orlitzky]

On 02/08/2018 06:12 PM, William Hubbs wrote:
> 
> There is no bug here. The problem, as I said before in this thread, is
> that what goes in *sbin is arbitrary, and as Rich said, if you are
> relying on the path to prevent a non-root user from running something
> that only root should run, you are doing it wrong. All the user has to
> do is type a full path to a command and it will be run.

The FHS says /usr/sbin is for "binaries used exclusively by the system
administrator." It's not arbitrary, and the test for what doesn't belong
there is obvious: if a regular user needs something in /usr/sbin, then
we put it in the wrong place. Adding /usr/sbin to PATH will hide the
fact that we put it in the wrong place, but it will still be in the
wrong place.

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[Rich Freeman]

On Thu, Feb 8, 2018 at 6:25 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
> On 02/08/2018 06:12 PM, William Hubbs wrote:
>>
>> There is no bug here. The problem, as I said before in this thread, is
>> that what goes in *sbin is arbitrary, and as Rich said, if you are
>> relying on the path to prevent a non-root user from running something
>> that only root should run, you are doing it wrong. All the user has to
>> do is type a full path to a command and it will be run.
>
> The FHS says /usr/sbin is for "binaries used exclusively by the system
> administrator." It's not arbitrary, and the test for what doesn't belong
> there is obvious: if a regular user needs something in /usr/sbin, then
> we put it in the wrong place. Adding /usr/sbin to PATH will hide the
> fact that we put it in the wrong place, but it will still be in the
> wrong place.
>

Sounds like a good reason to refer bugs upstream, and hide them from
users in the meantime, like basically every other distro does.

-- 
Rich

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[Mike Auty]

[-- Attachment #1.1: Type: text/plain, Size: 513 bytes --]

On 08/02/18 20:55, Mike Gilbert wrote:
> However, there are plenty of examples of commands that normal users
> may run from sbin.
Hiya,

I'm not really for or against the idea, but whenever the justification
for something is "there are plenty of examples" it's really helpful to
have a number of them listed so that people can see what actual benefit
is being provided by the change.  Could you name a few of the most
common/important examples so that it's part of the discussion please?

Mike  5:)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 368 bytes --]

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[Michał Górny]

W dniu sob, 10.02.2018 o godzinie 10∶49 +0000, użytkownik Mike Auty
napisał:
> On 08/02/18 20:55, Mike Gilbert wrote:
> > However, there are plenty of examples of commands that normal users
> > may run from sbin.
> 
> Hiya,
> 
> I'm not really for or against the idea, but whenever the justification
> for something is "there are plenty of examples" it's really helpful to
> have a number of them listed so that people can see what actual benefit
> is being provided by the change.  Could you name a few of the most
> common/important examples so that it's part of the discussion please?
> 

blkid
btrfs
iwconfig
swapon

I think historically also 'ifconfig' and 'ping' were in sbin.

Sure, those commands are often used by root. But I don't need elevated
privileges to want to know my free space or IP address.

-- 
Best regards,
Michał Górny

[gentoo-dev] Re: newsitem: baselayout 2.5 changes

[Duncan]

William Hubbs posted on Thu, 08 Feb 2018 13:52:56 -0600 as excerpted:

> here is a proposed newsitem for baselayout 2.5.

> There are three significant changes in baselayout-2.5.
> 
> The first change is that ROOTPATH is no longer set. This means all of
> the *sbin directories will be added to the default path for all users
> instead of just the root user.

Makes sense and is important for users to know.

> I know of no packages outside of
> baselayout that used the ROOTPATH variable; however, if packages do use
> it, they will need to be adjusted to use PATH instead.

Omit that as dev, not user, focused?

> The second change is that baselayout is taking ownership of most of the
> directories it creates. This includes all directories in / and /usr
> excluding /lib* and /usr/lib*. Once we drop support for SYMLINK_LIB,
> baselayout will take ownership of /lib* and /usr/lib* as well.

What's the effect if the "directory" is a symlink to elsewhere?

Here, the following system "directories" are actually symlinks:

# makes installing grub to multiple devices much easier
/boot -> /bt

# "reverse" usrmerge
/usr -> .

# would be /usr/games, but with reverse usrmerge...
/game -> .

# shorter path
/home -> h

# lib(64) merge (including /usr/lib(64)
/lib -> lib64

# would be /usr/local, /l is so much shorter
/local -> l

# (s)bin merge (including /usr/(s)bin)
/sbin -> bin

# shouldn't appear on a desktop/workstation system, but bugs...
/srv -> tmp

# shorter log path (/lg as /l already taken by local)
/var/log -> /lg

> Third is the beginning of support for the /usr merge through the
> addition of the usrmerge use flag.
> DO NOT, DO NOT TURN THIS ON UNLESS YOU KNOW WHAT YOU ARE DOING AND CAN
> HELP WITH TESTING.

What about "reverse" usrmerge as above?  Flag on or not?  Maybe I just 
turn it on (obviously after updating my backups) to help test?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: newsitem: baselayout 2.5 changes

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2495 bytes --]

On Sat, Feb 10, 2018 at 03:34:51PM +0000, Duncan wrote:
> William Hubbs posted on Thu, 08 Feb 2018 13:52:56 -0600 as excerpted:

*snip*

> > The second change is that baselayout is taking ownership of most of the
> > directories it creates. This includes all directories in / and /usr
> > excluding /lib* and /usr/lib*. Once we drop support for SYMLINK_LIB,
> > baselayout will take ownership of /lib* and /usr/lib* as well.
> 
> What's the effect if the "directory" is a symlink to elsewhere?
 
When we try to replace the symlink with a directory, the emerge will
fail.

You  will want to take a look at using /etc/portage/package.env and
/etc/portage/env/baselayout to set INSTALL_MASK to not install things
that collide if you want to keep this setup.

https://wiki.gentoo.org/wiki//etc/portage/package.env

> Here, the following system "directories" are actually symlinks:
> 
> # makes installing grub to multiple devices much easier
> /boot -> /bt
> 
> # "reverse" usrmerge
> /usr -> .
> 
> # would be /usr/games, but with reverse usrmerge...
> /game -> .
> 
> # shorter path
> /home -> h
> 
> # lib(64) merge (including /usr/lib(64)
> /lib -> lib64

When we get rid of symlink_lib, we will expect both of these (/lib and
/lib64) to be directories. Mgorny can explain more about this, but
linking lib to lib64 is basically a hack.


> 
> # would be /usr/local, /l is so much shorter
> /local -> l
> 
> # (s)bin merge (including /usr/(s)bin)
> /sbin -> bin

This will be taken care of in the usr merge support.

> 
> # shouldn't appear on a desktop/workstation system, but bugs...
> /srv -> tmp

Keep in mind that /tmp is wiped during a reboot, so /srv should be
separate from /tmp.

> 
> # shorter log path (/lg as /l already taken by local)
> /var/log -> /lg
> 
> > Third is the beginning of support for the /usr merge through the
> > addition of the usrmerge use flag.
> > DO NOT, DO NOT TURN THIS ON UNLESS YOU KNOW WHAT YOU ARE DOING AND CAN
> > HELP WITH TESTING.
> 
> What about "reverse" usrmerge as above?  Flag on or not?  Maybe I just 
> turn it on (obviously after updating my backups) to help test?

The "reverse" usr merge as you call it is a highly custom configuration;
I do not see us building it into baselayout. However, like I said above,
the baselayout changes will not stop you from configuring this using a
combination of /etc/portage/package.env and /etc/portage/env/baselayout.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: newsitem: baselayout 2.5 changes

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2802 bytes --]

On Sat, Feb 10, 2018 at 12:15:43PM -0600, William Hubbs wrote:
> On Sat, Feb 10, 2018 at 03:34:51PM +0000, Duncan wrote:
> > William Hubbs posted on Thu, 08 Feb 2018 13:52:56 -0600 as excerpted:
> 
> *snip*
> 
> > > The second change is that baselayout is taking ownership of most of the
> > > directories it creates. This includes all directories in / and /usr
> > > excluding /lib* and /usr/lib*. Once we drop support for SYMLINK_LIB,
> > > baselayout will take ownership of /lib* and /usr/lib* as well.
> > 
> > What's the effect if the "directory" is a symlink to elsewhere?
>  
> When we try to replace the symlink with a directory, the emerge will
> fail.

It looks like this isn't quite correct, portage doesn't fail to emerge
the package, but it doesn't replace the symlink with the directory
either. You may be ok, but you'll have to test.

This is all very custom (Gentoo makes these things as directories when
the stages are built, so it won't be an issue for a default
installation).

> > Here, the following system "directories" are actually symlinks:
> > 
> > # makes installing grub to multiple devices much easier
> > /boot -> /bt
> > 
> > # "reverse" usrmerge
> > /usr -> .
> > 
> > # would be /usr/games, but with reverse usrmerge...
> > /game -> .
> > 
> > # shorter path
> > /home -> h
> > 
> > # lib(64) merge (including /usr/lib(64)
> > /lib -> lib64
> 
> When we get rid of symlink_lib, we will expect both of these (/lib and
> /lib64) to be directories. Mgorny can explain more about this, but
> linking lib to lib64 is basically a hack.
> 
> 
> > 
> > # would be /usr/local, /l is so much shorter
> > /local -> l
> > 
> > # (s)bin merge (including /usr/(s)bin)
> > /sbin -> bin
> 
> This will be taken care of in the usr merge support.
> 
> > 
> > # shouldn't appear on a desktop/workstation system, but bugs...
> > /srv -> tmp
> 
> Keep in mind that /tmp is wiped during a reboot, so /srv should be
> separate from /tmp.
> 
> > 
> > # shorter log path (/lg as /l already taken by local)
> > /var/log -> /lg
> > 
> > > Third is the beginning of support for the /usr merge through the
> > > addition of the usrmerge use flag.
> > > DO NOT, DO NOT TURN THIS ON UNLESS YOU KNOW WHAT YOU ARE DOING AND CAN
> > > HELP WITH TESTING.
> > 
> > What about "reverse" usrmerge as above?  Flag on or not?  Maybe I just 
> > turn it on (obviously after updating my backups) to help test?
> 
> The "reverse" usr merge as you call it is a highly custom configuration;
> I do not see us building it into baselayout. However, like I said above,
> the baselayout changes will not stop you from configuring this using a
> combination of /etc/portage/package.env and /etc/portage/env/baselayout.
> 
> William
> 



[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[gentoo-dev] Re: newsitem: baselayout 2.5 changes

[Duncan]

William Hubbs posted on Sat, 10 Feb 2018 12:43:08 -0600 as excerpted:

> This is all very custom (Gentoo makes these things as directories when
> the stages are built, so it won't be an issue for a default
> installation).

Of course Gentoo is a rolling distro... no need to periodically reinstall.

While I'm almost certainly an extreme example, people /will/ have a "non-
default" install in one way or another after say a decade-ish of 
rolling.  After all, if they weren't interested in that sort of "power" 
modifications, they'd likely be long gone well before the decade, off to 
some "easier" distro as it wouldn't be worth their trouble.

FWIW I've been continuously rolling the same original install forward 
thru hardware, software, and needs changes, for nearing a decade and half 
now.  I'd argue it'd be the rare Gentoo install indeed that remains 
"default state" after that sort of time.

Which is why these news items are so critically important.  Ideally, they 
provide not only a "default install" recipe, but two additional pieces of 
critical information as well:

1) What sort of non-default site/install mods are likely to be affected.  

(These need not be too specific, just something like, in this case, 
"People with symlinks to alternative directory locations or similar site-
specific solutions may need to take particular care here. ...")

2) Preferably some hint at what might be needed.

("... Refreshing your backups before the upgrade and checking site-
specific solutions after the upgrade before reboot, is recommended.")

Because it's a system-critical package this becomes even more important.

(And FWIW, getting a longer heads-up to such changes is a primary reason 
I read this list.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: newsitem: baselayout 2.5 changes

[Duncan]

William Hubbs posted on Sat, 10 Feb 2018 12:15:43 -0600 as excerpted:

>> # shouldn't appear on a desktop/workstation system, but bugs...
>> /srv -> tmp
> 
> Keep in mind that /tmp is wiped during a reboot, so /srv should be
> separate from /tmp.

FWIW that was deliberate. Indeed, /tmp is tmpfs here. =:^)

TL;DR: Stop.

The package in question (some indexer kde4 used for its handbooks, IIRC, 
I'm not even sure it's still needed for frameworks-5 based handbooks or 
whether it's still installed) is primarily used in web servers and the 
like, and installed something in /srv to facilitate that.

But I didn't need it, was irritated by it, and decided to set things up 
both to make it temporary, and to create an extremely obvious failure if 
anything else should ever install anything to /srv that I might actually 
need more permanently, so with more information if it ever triggered, I 
could decide on appropriate measures.  FWIW, nothing has ever triggered 
it, so if anything else is or has installed anything to /srv, it's 
obviously not anything I depend on after a reboot.

Of course I could do something similar with a global INSTALL_MASK, but 
having it pointed at a tmpfs instead lets me examine what's actually 
installed, if necessary.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[Benda Xu]

[-- Attachment #1: Type: text/plain, Size: 1441 bytes --]

Hi William,

William Hubbs <williamh@gentoo.org> writes:

> here is a link to an old, but brief discussion about this.
>
> https://archives.gentoo.org/gentoo-dev/message/2fc1f62c7cf225787fe52f4dace7368c
>
> I think we have talked about this several other times, but not done
> anything about it.
>
> On Thu, Feb 08, 2018 at 10:17:59PM +0000, M. J. Everitt wrote:
>> 
>> Pardon my ignorance, but does that mean you are essentially relying on
>> file system features/permissions and security settings to enforce
>> correct use of system tools?! Or is this just to make sudo/etc commands
>> 'more convenient' ?!
>
> The basic problem is that what goes in *bin vs *sbin is quite arbitrary
> and the best way to fix it is to make all of the *bin and *sbin
> directories accessible to all users.
>
> You can't rely on a path to separate system-only programs from
> programs that users might want to run, and some programs can be run by
> users to look around but not change things.
>
> Here is one non-gentoo source discussing this.
>
> http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
>
> Even if we don't adopt the usr merge in Gentoo Linux as default, removing *sbin
> from the path doesn't make sense.

If there references are useful for users to understand why this decision
and potential breakage is made, it might be a good idea to append the
links to the news item.

Yours,
Benda

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[Benda Xu]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

Hi William,

William Hubbs <williamh@gentoo.org> writes:

> The second change is that baselayout is taking ownership of most of the
> directories it creates. This includes all directories in / and /usr
> excluding /lib* and /usr/lib*. Once we drop support for SYMLINK_LIB,
> baselayout will take ownership of /lib* and /usr/lib* as well.

This is an abrupt change that will affect many users.  I suggest a
lengthy explanation (blog post, wiki page or important emails) to be
attached as a reference in this news item.  

So a user will be able to study the rationales behind this change before
unmasking baselayout-2.5 on their machines.

Yours,
Benda

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

On Sun, Feb 18, 2018 at 11:07:59AM +0900, Benda Xu wrote:
> Hi William,
> 
> William Hubbs <williamh@gentoo.org> writes:
> 
> > The second change is that baselayout is taking ownership of most of the
> > directories it creates. This includes all directories in / and /usr
> > excluding /lib* and /usr/lib*. Once we drop support for SYMLINK_LIB,
> > baselayout will take ownership of /lib* and /usr/lib* as well.
> 
> This is an abrupt change that will affect many users.  I suggest a
> lengthy explanation (blog post, wiki page or important emails) to be
> attached as a reference in this news item.  
> 
> So a user will be able to study the rationales behind this change before
> unmasking baselayout-2.5 on their machines.

Baselayout currently goes out of its way not to own these, but there's
no rationale documented anywhere for why it does this.

From what I've seen in some testing I've done, it shouldn't break
anything. I will test again before I actually push the release on
another machine.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]