newsitem: baselayout 2.5 changes

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

newsitem: baselayout 2.5 changes

William Hubbs
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


2018-02-xx-baselayout-25-changes.en.txt (1K) Download Attachment
signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: newsitem: baselayout 2.5 changes

Mike Gilbert-2
On Thu, Feb 8, 2018 at 2:52 PM, William Hubbs <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: newsitem: baselayout 2.5 changes

Ulrich Mueller-2
>>>>> 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

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: newsitem: baselayout 2.5 changes

Mike Gilbert-2
On Thu, Feb 8, 2018 at 3:41 PM, Ulrich Mueller <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: newsitem: baselayout 2.5 changes

William Hubbs
On Thu, Feb 08, 2018 at 03:55:02PM -0500, Mike Gilbert wrote:
> On Thu, Feb 8, 2018 at 3:41 PM, Ulrich Mueller <[hidden email]> 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


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: newsitem: baselayout 2.5 changes

M. J. Everitt


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


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: newsitem: baselayout 2.5 changes

Michael Orlitzky
In reply to this post by William Hubbs
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.

Reply | Threaded
Open this post in threaded view
|

Re: newsitem: baselayout 2.5 changes

Rich Freeman
In reply to this post by M. J. Everitt
On Thu, Feb 8, 2018 at 5:17 PM, M. J. Everitt <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: newsitem: baselayout 2.5 changes

William Hubbs
In reply to this post by M. J. Everitt
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
>




signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: newsitem: baselayout 2.5 changes

M. J. Everitt
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.


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: newsitem: baselayout 2.5 changes

Michael Orlitzky
In reply to this post by Rich Freeman
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.

Reply | Threaded
Open this post in threaded view
|

Re: newsitem: baselayout 2.5 changes

William Hubbs
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


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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.

Reply | Threaded
Open this post in threaded view
|

Re: newsitem: baselayout 2.5 changes

Rich Freeman
On Thu, Feb 8, 2018 at 6:25 PM, Michael Orlitzky <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: newsitem: baselayout 2.5 changes

Mike Auty-3
In reply to this post by Mike Gilbert-2
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:)


signature.asc (378 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: newsitem: baselayout 2.5 changes

Michał Górny-5
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


Reply | Threaded
Open this post in threaded view
|

Re: newsitem: baselayout 2.5 changes

Duncan-42
In reply to this post by William Hubbs
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


Reply | Threaded
Open this post in threaded view
|

Re: newsitem: baselayout 2.5 changes

William Hubbs
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


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: newsitem: baselayout 2.5 changes

William Hubbs
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
>


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: newsitem: baselayout 2.5 changes

Duncan-42
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


12