On Fri, Jan 07, 2022 at 11:44:59AM +0100, Didier Kryn wrote:
> Le 07/01/2022 à 10:18, Didier Kryn a écrit :
> > Le 06/01/2022 à 22:00, Bob Proulx via Dng a écrit :
> > > Didier Kryn wrote:
> > > > Hendrik Boom a ecrit :
> > > > > > > software that isn't properly packaged as a .deb, but
> > > > > > > instead has an "installer" that needs to be run as root.
> > > Immediately I think of all of those script "installers" that
> > > request the user do this and similar to install their software as
> > > root this way.
> > >
> > >      wget -O- http:/example.com/foo.sh | bash
> > >
> > > How many projects do this?  Hundreds?  Thousands?
> > >
> > > In real life I have encountered many CAD/EDA tool vendors with
> > > installation scripts that casually make system modifications not
> > > knowing what they do.  I try to keep those contained.

If I recall correctly, the manufacturer-supplied printer driver for the
Brother HL 3170CDW laser printer does this.

> > >
> > > In real life I have encountered sysadmins who have casually
> > > modified modules, python in this case but it could have been
> > > other, in /usr/lib outside of the package manager or any
> > > tracking.  Then later normal machine upgrades were broken because
> > > newer modules were broken by upgrading older ones.  If those had
> > > been made into /usr/local instead it would have been both visible
> > > and would not have been broken by normal system upgrades.
> > >
> > > Being more than twice burned I am extremely shy now...
> > >
> > > > > >      If the installer must be run as root, it is precisely
> > > > > > because it needs to install software in /usr.
> > > Or into /usr/local which now requires root.  Back in the better
> > > days of Debian it used to be possible for a user of group staff
> > > to install into /usr/local without full superuser access.  But
> > > that's gone from the installation now.
> > >
> > >      https://bugs.debian.org/484841#62
> > >
> > > Since that has been removed in favor of using full root for
> > > everything it removes a useful safety net layer.  For example
> > > this statement.
> > >
> > >      Russ Allbery writes in comment #77 in favor of using full
> > > root      instead of a more limited group staff.
> > >
> > >      I would prefer to drop the writeability of /usr/local by
> > > staff      personally.  I don't think it serves much useful
> > > purpose these days      given the existence of tools like sudo,
> > > and where it does, I think we      can work out a transition plan
> > > that will make it relatively easy for      sites to recreate the
> > > concept.
> > >
> > > And the vote went against it.  So it's gone now.  It's root only.
> > > Sigh.  On my systems I recreate the group staff concept and
> > > implementation.  Because I do find it useful.

My chimaera system says

hendrik@midwinter:~$ ls /usr/local -l
total 36
drwxrwsr-x  2 root    staff 4096 Jun  1  2021 bin
drwxrwsr-x  2 root    staff 4096 Jul  9  2018 etc
drwxrwsr-x  2 root    staff 4096 Jul  9  2018 games
drwxrwsr-x  2 root    staff 4096 Jul  9  2018 include
drwxrwsr-x  4 root    staff 4096 Oct  5 08:27 lib
lrwxrwxrwx  1 root    staff    9 Jul  9  2018 man -> share/man
drwxr-sr-x 10 hendrik staff 4096 Jun  1  2021 racket
drwxrwsr-x  2 root    staff 4096 Jul  9  2018 sbin
drwxrwsr-x  9 root    staff 4096 Oct  5 08:21 share
drwxrwsr-x  2 root    staff 4096 Jul  9  2018 src

so it looks as if 'staff' is still alive.
I certainly didn't set up a 'staff' account myself.

...
...

>
>
> Concerning installation in /usr/local:
> --------------------------------------
>
>     My first investigations indicate that there is provision in
> Freedesktop.org to put icons and launchers under $HOME/.local, but
> nothing for /usr/local. Therefore the installation of an application
> in /usr/local could include executable, config files and manpages,
> but the icon and the launcher would be per user.     Seems /usr/local
> is honoured by the base system (default PATH and default man search
> path) but is "deprecated" by Freedesktop.
>
>
> Concerning installation in user's space:
> ----------------------------------------
>
>     As written above, Freedesktop enables icons, launchers and
> applications menu in ~/.local . Man will look also by default search
> ~/man if it exists, but, to my knowledge, there is no default user
> directory for executables; it is therefore up to the user to create
> this directory and specify it when installing, which makes
> uninstallation problematic.
>
>     In this case, the installer might force the use of ~/bin and
> ~/man and create them if they don't exist.

It is not unusual for a non-distro package, let's call it foo, to
install *all* of its files in /usr/local/foo .

Sometimes the installer for such a package is so kind as to ask the
user where to install, with /usr/local/foo as default location.

Then the user is expected or told to put things on her PATHs
appripriately.

The installer can of course customise the various scripts and
executables within the package so as to point to wherever the package
got installed.

It's also not unusual for a package installed in /usr/local to set
symbolic links all over the file system to point from where the system
might expect them to the appropriate place in /usr/local/...

It the package is subsequently ninstalled by rm -r /user/local/foo
all those links will show up as dangling links. System montirs like
tiger can find such links.

In fact, there's a command 'stow' that is designed to keep track of
such symbolic links. stow is part of the package called 'stow', which
is unfortunately not part of the default install.

-- hendrik