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@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
::
Re: [DNG] merged /usr breakage
