On 1/7/22 8:59 AM, Hendrik Boom wrote:
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.
...
...
Just another data point.
kdibble@thinkstation:~$ ls -l /usr/local
total 32
drwxr-xr-x 2 root root 4096 Oct 14 08:23 bin
drwxr-xr-x 2 root root 4096 Oct 14 08:23 etc
drwxr-xr-x 2 root root 4096 Oct 14 08:23 games
drwxr-xr-x 2 root root 4096 Oct 14 08:23 include
drwxr-xr-x 3 root root 4096 Dec 4 18:59 lib
lrwxrwxrwx 1 root root 9 Oct 14 08:23 man -> share/man
drwxr-xr-x 2 root root 4096 Oct 14 08:23 sbin
drwxr-xr-x 10 root root 4096 Oct 20 11:37 share
drwxr-xr-x 2 root root 4096 Oct 14 08:23 src
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
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
