Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 09/01/2022 à 13:23, Benjamin Riefenstahl a écrit :

Hi Didier,


Didier Kryn writes:

But the launchers are to be installed/uninstalled by every user in
their own ~/.local

benny wrote:

What happens, if you add another user after installation?  AFAIU default
launchers should be in a global place.

Didier Kryn writes:

     We want to install files only under /usr/local, and, for
Freedesktop.org, there's no other global place than
/usr/share/applications. Full point (AFAIK). I agree with you it's not
very clever.

Oh, you mean, the installer would tell the users to install the desktop
files themself, via xdg-install-icon?  I don't think that works very
well.
    Just cp '/usr/local/share/applications/foobar.desktop 
~/.local/applications/'
    The installer script certainly would not. But the admin might 
suggest them to.


Anyway,

says that /usr/local/share/applications should work fine, so there
should be no problem.


   Good finding. Actually in my session XDG_DATA_DIRS is set as you 
write. It seems it is set in /etc/alternatives/x-session-manager.


    Still one point has not been discussed yet: the config file is 
currently in /etc .


    The Linux Foundation suggests it should be put in /usr/local/etc 
(https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html


    So it seems everything is clear now. Thanks to all. I will make the 
software install in /usr/local. DO you fiond this satisfactory Hendrik?


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Benjamin Riefenstahl]

Hi Didier,

>> Didier Kryn writes:
>>> But the launchers are to be installed/uninstalled by every user in
>>> their own ~/.local

benny wrote:
>> What happens, if you add another user after installation?  AFAIU default
>> launchers should be in a global place.

Didier Kryn writes:
>     We want to install files only under /usr/local, and, for
> Freedesktop.org, there's no other global place than
> /usr/share/applications. Full point (AFAIK). I agree with you it's not
> very clever.

Oh, you mean, the installer would tell the users to install the desktop
files themself, via xdg-install-icon?  I don't think that works very
well.

Anyway,

says that /usr/local/share/applications should work fine, so there
should be no problem.

> Freedesktop might forbid it as well...

Freedesktop does not forbid anything, they couldn't even if they tried.

so long, benny
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 08/01/2022 à 20:40, Benjamin Riefenstahl a écrit :

Hi Didier,

Didier Kryn writes:

But the launchers are to be installed/uninstalled by every user in
their own ~/.local

What happens, if you add another user after installation?  AFAIU default
launchers should be in a global place.

    We want to install files only under /usr/local, and, for 
Freedesktop.org, there's no other global place than 
/usr/share/applications. Full point (AFAIK). I agree with you it's not 
very clever.


    Users could make their .local/applications be a symlink to 
/usr/local/share/applications. This is not a standard and they would 
loose the ability to have their own private entries in their 
applications menu. I think very few users actually have private entries 
in their applications menu - this is not the same as launchers on the 
desktop. Therefore this symlink could be considered as a workaround: the 
applications menu would only expose globally installed applications, 
either provided by the distro or in /usr/local. It still has to be 
tested; Freedesktop might forbid it as well...


--  Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Benjamin Riefenstahl]

Hi Didier,

Didier Kryn writes:
> But the launchers are to be installed/uninstalled by every user in
> their own ~/.local

What happens, if you add another user after installation?  AFAIU default
launchers should be in a global place.

benny
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 08/01/2022 à 17:18, tito via Dng a écrit :

On Sat, 8 Jan 2022 15:56:19 +0100
Didier Kryn  wrote:


Le 07/01/2022 à 23:27, Hendrik Boom a écrit :
    Install can be user-configurable, this is easy, but the package 
provides
the way to uninstall and, for the uninstall to work, the install 
must be
hardcoded because the source of the package cannot remember what 
the user

has done at install time.

So the installer can create the appropriate uninstall script, based on
the parameters the user has provided.

Then the uninstall script will have the user's own locations hardcoded
into it.

    And what do you do with the uninstall script ? Is there any
standard place to store it, under what name?

    Currently, if you install hopman, you can get rid of the source.
Then, if you need to remove it, just download the source again, unpack
it and run 'make uninstall'. Having an uninstall script (actually a
makefile) is not a bad idea. We just need a standard place to put it. 
Ideas?


--     Didier


Hi,

Option A:

put it inside hopman itself.
It will get the cwd of the hopman binary,
assume that the prefix to uninstall
the other files is one level up,
create the paths and uninstall.
For example, installed in /usr/local/bin/hopman:
hopman --uninstall
are you sure? yes
getcwd returns /usr/local/bin
prefix is strrchr("/usr/local/bin", '/') => /usr/local
paths are:
prefix/etc/hopman.conf
prefix/bin/hopman/helperbin
prefix/bin/hopman
for list of paths
if paths exists rm paths

Should work with all prefixes /, ~/bin, /usr/local, /opt.

Option B:
assume that path prefix is known at compile time
hardcode the paths in the binary
remove the hardcoded paths at uninstall time

Option B1:
it would be nice if sha sums of the files to be removed
could be stored into the binary to be sure to remove the right
ones (doesn't apply to conf files if there are some).


    If you install in /usr/local, everything is standard and can be 
hardcoded and install/uninstall is done by the owner of /usr/local. But 
the launchers are to be installed/uninstalled by every user in their own 
~/.local


    When installing on /opt your method seems best. At the end the 
uninstall script must delete itself, but there is certainly a trick to 
do that. Note however that it adds quite a lot of complexity to the 
application, plus one file to install: the uninstall script. In this 
case, every user must install the launchers, but also update his PATH 
and MANPATH.


    When installing in the user's home, your method can 
install/uninstall everything and is also responsible of his PATH and 
MANPATH.


--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[tito via Dng]

On Sat, 8 Jan 2022 15:56:19 +0100
Didier Kryn  wrote:

> Le 07/01/2022 à 23:27, Hendrik Boom a écrit :
> >>      Install can be user-configurable, this is easy, but the package 
> >> provides
> >> the way to uninstall and, for the uninstall to work, the install must be
> >> hardcoded because the source of the package cannot remember what the user
> >> has done at install time.
> > So the installer can create the appropriate uninstall script, based on
> > the parameters the user has provided.
> >
> > Then the uninstall script will have the user's own locations hardcoded
> > into it.
> 
>      And what do you do with the uninstall script ? Is there any 
> standard place to store it, under what name?
> 
>      Currently, if you install hopman, you can get rid of the source. 
> Then, if you need to remove it, just download the source again, unpack 
> it and run 'make uninstall'. Having an uninstall script (actually a 
> makefile) is not a bad idea. We just need a standard place to put it. Ideas?
> 
> --     Didier
> 

Hi,

Option A:

put it inside hopman itself.
It will get the cwd of the hopman binary,
assume that the prefix to uninstall
the other files is one level up,
create the paths and uninstall.
For example, installed in /usr/local/bin/hopman:
hopman --uninstall
are you sure? yes
getcwd returns /usr/local/bin
prefix is strrchr("/usr/local/bin", '/') => /usr/local
paths are:
prefix/etc/hopman.conf
prefix/bin/hopman/helperbin
prefix/bin/hopman
for list of paths
if paths exists rm paths

Should work with all prefixes /,  ~/bin, /usr/local, /opt.

Option B:
assume that path prefix is known at compile time
hardcode the paths in the binary
remove the hardcoded paths at uninstall time

Option B1:
it would be nice if sha sums of the files to be removed
could be stored into the binary to be sure to remove the right
ones (doesn't apply to conf files if there are some).

Just some horrible hacks, untested.

Ciao,
Tito
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 07/01/2022 à 23:27, Hendrik Boom a écrit :

     Install can be user-configurable, this is easy, but the package provides
the way to uninstall and, for the uninstall to work, the install must be
hardcoded because the source of the package cannot remember what the user
has done at install time.

So the installer can create the appropriate uninstall script, based on
the parameters the user has provided.

Then the uninstall script will have the user's own locations hardcoded
into it.


    And what do you do with the uninstall script ? Is there any 
standard place to store it, under what name?


    Currently, if you install hopman, you can get rid of the source. 
Then, if you need to remove it, just download the source again, unpack 
it and run 'make uninstall'. Having an uninstall script (actually a 
makefile) is not a bad idea. We just need a standard place to put it. Ideas?


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Hendrik Boom]

On Fri, Jan 07, 2022 at 05:48:08PM +0100, Didier Kryn wrote:
> Le 07/01/2022 à 12:13, Olaf Meeuwissen a écrit :
> > > 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.
> > If I were you I would make the installation locations configurable, at
> > least at build time with an option to override at install time.
> > 
> > Don't know if you have any experience with building GNU software from
> > source but the ./configure command has options to set a whole pile of
> > locations:
> > 
> > - bindir
> > - libdir
> > - mandir
> > - ...
> > 
> > by default these locations are below a configurable prefixdir that
> > defaults to /usr/local so you get to install below
> > 
> > - /usr/local/bin
> > - /usr/local/lib
> > - /usr/local/man
> > -/usr/local/...
> > 
> > If the user runs ./configure --prefix=$HOME then everything will end up
> > below $HOME. If that user also added --mandir=/usr/local/man then only
> > the manual pages would end up there, everything else still goes below
> > $HOME.
> > 
> > Often the resulting Makefile allows specifying a staging location, a
> > destdir, so you can easily bundle the installed result, in a Debian
> > package for example;-). Setting destdir to /tmp/test, would install
> > that $HOME configured build in
> > 
> > -/tmp/test/$HOME/bin
> > -/tmp/test/$HOME/lib
> > - /tmp/test/usr/local/man
> > -/tmp/test/$HOME/...
> > 
> > but at run-time still use the location without the /tmp/test prefix.
> > 
> > Long story short, don't try to decide the final locations but make them
> > configurable and let the builder decide. Just organize the locations
> > using things like bindir, libdir, etc and make your code use whatever
> > was configured at build time.
> > 
> > I realize that autoconf may be less popular than it once was (cmake is
> > gaining popularity, it seems) but its documentation has a section on the
> > various installation locations it supports. Perhaps that can serve as a
> > guide for picking the places you need.
> > 
> > https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/autoconf.html#Installation-Directory-Variables
> 
>     First I won't use GNU autotools they're very complicated and they make
> Makefiles unreadable and, in this case, it's a hammer to kill a fly.
> 
>     Install can be user-configurable, this is easy, but the package provides
> the way to uninstall and, for the uninstall to work, the install must be
> hardcoded because the source of the package cannot remember what the user
> has done at install time.

So the installer can create the appropriate uninstall script, based on 
the parameters the user has provided. 

Then the uninstall script will have the user's own locations hardcoded 
into it.

-- hendrik.

> 
>     Therefore there must be some standard locations where to put files. I
> could provide three options: /usr, /usr/local and $HOME. Then, the uninstall
> could find its way automatically, but, in the case /usr/local, it would be
> up to every user to create symlinks to icon and launcher, and in the case of
> $HOME, the directories bin and man would be created automatically.
> 
> --     Didier
> 
> 
> 
> 
> ___
> 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

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 07/01/2022 à 12:13, Olaf Meeuwissen a écrit :

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.

If I were you I would make the installation locations configurable, at
least at build time with an option to override at install time.

Don't know if you have any experience with building GNU software from
source but the ./configure command has options to set a whole pile of
locations:

- bindir
- libdir
- mandir
- ...

by default these locations are below a configurable prefixdir that
defaults to /usr/local so you get to install below

- /usr/local/bin
- /usr/local/lib
- /usr/local/man
-/usr/local/...

If the user runs ./configure --prefix=$HOME then everything will end up
below $HOME. If that user also added --mandir=/usr/local/man then only
the manual pages would end up there, everything else still goes below
$HOME.

Often the resulting Makefile allows specifying a staging location, a
destdir, so you can easily bundle the installed result, in a Debian
package for example;-). Setting destdir to /tmp/test, would install
that $HOME configured build in

-/tmp/test/$HOME/bin
-/tmp/test/$HOME/lib
- /tmp/test/usr/local/man
-/tmp/test/$HOME/...

but at run-time still use the location without the /tmp/test prefix.

Long story short, don't try to decide the final locations but make them
configurable and let the builder decide. Just organize the locations
using things like bindir, libdir, etc and make your code use whatever
was configured at build time.

I realize that autoconf may be less popular than it once was (cmake is
gaining popularity, it seems) but its documentation has a section on the
various installation locations it supports. Perhaps that can serve as a
guide for picking the places you need.

https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/autoconf.html#Installation-Directory-Variables


    First I won't use GNU autotools they're very complicated and they 
make Makefiles unreadable and, in this case, it's a hammer to kill a fly.


    Install can be user-configurable, this is easy, but the package 
provides the way to uninstall and, for the uninstall to work, the 
install must be hardcoded because the source of the package cannot 
remember what the user has done at install time.


    Therefore there must be some standard locations where to put files. 
I could provide three options: /usr, /usr/local and $HOME. Then, the 
uninstall could find its way automatically, but, in the case /usr/local, 
it would be up to every user to create symlinks to icon and launcher, 
and in the case of $HOME, the directories bin and man would be created 
automatically.


--     Didier




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 07/01/2022 à 13:06, Benjamin Riefenstahl a écrit :

Hi Didier,

Didier Kryn writes:

    My first investigations indicate that there is provision in
Freedesktop.org to put icons and launchers under $HOME/.local, but
nothing for /usr/local.

I do not think that ~/.local is related to /usr/local in any meaningfull
way. /usr/local is for the administrator to put self-compiled stuff
there, stuff that should be avaiable for all accounts on the machine.
Used to be, that in some environments that directory was on a network
share, so these packages were immediatly available on all machines in
the local network.


    This is exactly what I wrote (or meant). Freedesktop provides for 
private declarations but not for anything in /usr/local, while the Linux 
command-line-ecosystem considers /usr/local as a legitimate place to put 
applications and their manpages.






    Seems /usr/local is honoured by the base system (default PATH and
default man search path) but is "deprecated" by Freedesktop.

The distribution package manager and its packages have no business
installing anything there, so there is nothing to deprecate. That the
default install add /usr/local/bin to PATH and similarly for other
directories is just a convenience. Some of the BSDs do not do that
IIRC.

    We are talking of packages which do not belong to the distro.

    The default PATH is a convenience but something very standard I 
don't thing users remove from their profiles.



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.

Icon pictures can be in /usr/local. XDG desktop files (which make the
applications show up in the Gnome shell and other DEs) can be installed
in /etc/xdg, like the packages from the package manager do. It is
possible that Gnome/XDG also looks into /usr/local/etc/xdg or some
similar place in addition to /etc/xdg, I haven't checked.


    I don't exacly know what /etc/xdg is. I think it contains some kind 
of template or default files as most files in /etc are. It is probably 
used when creating new users.


    The fact is that to make an application appear in the applications 
menu, there are two possible places to put the launcher: 
/usr/share/applications or ~/.local/applications .


    /etc belongs to root and has to. We are speaking of installing 
software without root permission.




/etc is used both by distribution packages and by packages in
/usr/local. Only distribution packages should install default
configurations there, and only if those files did not exist before or,
during an update, if they where not modified since installation or last
update.
    As written above, we don't want to give root permission to the 
installer.






to my knowledge, there is no default user directory for executables;

In some distibutions /etc/profile adds ~/bin to PATH, if it exists.
Again this is just a convenience. In the end /etc is for the
administrator to set her/his own policy.


    Yes, at least in Debian. But the .profile, .bash_profile and 
.bashrc are very personnal things and the ~/bin directory has to be 
created explicitely by the user and some won't, some will prefer other 
names etc...


    What the user does with his subdirs is essentially personnal up to 
the advent of Freedesktop. Freedesktop forces some directories and 
files. This policy has two faces: on one face it is an abuse, on the 
other it facilitates standardization. What Freedesktop misses/disregards 
is /usr/local.


--     Didier



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Olaf Meeuwissen]

Hi Didier,

Didier Kryn  writes:

> 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.
>>>
>>> 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.
>>>
> Such software should be installing to /opt, but might not.
  Installing application and configuration files in /opt is a
 possibility,
 but what to do with man page, application launcher, entry in the
 application
 menu? Installing in /opt does not require to mount /usr readonly. Just
 create a particular user account for /opt and use it to
 install. Even one
 user and one subdir per application.
>>> Although I am not fully warmed up to /opt even after all of these
>>> years for each of these questions there is a strategy to handle it.
>>> PATH, MANPATH, desktop launcher files, and so forth.  But those are
>>> all already set up for /usr/local by default.  /opt by the nature of
>>> it being outside of the normal system then requires everything to be
>>> set up for it.  Which is possible and easily done.  But then also must
>>> be done if used.
>>>
>>  I have written such a software, called hopman. This
>> discussion suggests
>> me that I should provide the option to install it in a user's
>> directory,
>> without the need to be root, rather than install it system-wide.
>>> I would say yes.  If it is intended to be installed outside of being
>>> packaged for the system then it should be easily installed both by
>>> root (or the classic group staff) in /usr/local or by the user as
>>> non-root installed into the user's $HOME.
>>>
>>> Back in 2019 Didier Kryn wrote:
>>>  > cd hopman/hopman-1.0
>>>  > make && make install # You must be root to install
>>>  > Installed files: /usr/bin/hopman, ...
>>>
>>> I didn't follow things beyond this so do not know how things evolved,
>>> and it isn't fair of me to reach back into the original if it has
>>> improved and evolved since then.  Sorry.  My bad.  But in the above it
>>> really should install that into /usr/local/bin (or sbin) by default
>>> instead of /usr/bin.
>>>
>>> For my own environment I would run that as myself in group staff which
>>> can write to /usr/local/bin without root.  I would run it.  It would
>>> fail.  I would notice that it was trying to install into /usr/bin.  I
>>> would review and inspect.  I would then make adjustments so that on my
>>> system it installed into /usr/local.  Having a read-only /usr in order
>>> to detect these issues by preventing them is useful.  In my case
>>> readonly is achieved by not being root.  But since we are training a
>>> new generation

Re: [DNG] merged /usr breakage

[Ken Dibble]

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 rootstaff 4096 Jun  1  2021 bin
drwxrwsr-x  2 rootstaff 4096 Jul  9  2018 etc
drwxrwsr-x  2 rootstaff 4096 Jul  9  2018 games
drwxrwsr-x  2 rootstaff 4096 Jul  9  2018 include
drwxrwsr-x  4 rootstaff 4096 Oct  5 08:27 lib
lrwxrwxrwx  1 rootstaff9 Jul  9  2018 man -> share/man
drwxr-sr-x 10 hendrik staff 4096 Jun  1  2021 racket
drwxrwsr-x  2 rootstaff 4096 Jul  9  2018 sbin
drwxrwsr-x  9 rootstaff 4096 Oct  5 08:21 share
drwxrwsr-x  2 rootstaff 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 as

Re: [DNG] merged /usr breakage

[Hendrik Boom]

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 rootstaff 4096 Jun  1  2021 bin
drwxrwsr-x  2 rootstaff 4096 Jul  9  2018 etc
drwxrwsr-x  2 rootstaff 4096 Jul  9  2018 games
drwxrwsr-x  2 rootstaff 4096 Jul  9  2018 include
drwxrwsr-x  4 rootstaff 4096 Oct  5 08:27 lib
lrwxrwxrwx  1 rootstaff9 Jul  9  2018 man -> share/man
drwxr-sr-x 10 hendrik staff 4096 Jun  1  2021 racket
drwxrwsr-x  2 rootstaff 4096 Jul  9  2018 sbin
drwxrwsr-x  9 rootstaff 4096 Oct  5 08:21 share
drwxrwsr-x  2 rootstaff 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 

Re: [DNG] merged /usr breakage

[Benjamin Riefenstahl]

Hi Didier,

Didier Kryn writes:
>     My first investigations indicate that there is provision in
> Freedesktop.org to put icons and launchers under $HOME/.local, but 
> nothing for /usr/local.

I do not think that ~/.local is related to /usr/local in any meaningfull
way.  /usr/local is for the administrator to put self-compiled stuff
there, stuff that should be avaiable for all accounts on the machine.
Used to be, that in some environments that directory was on a network
share, so these packages were immediatly available on all machines in
the local network.

>     Seems /usr/local is honoured by the base system (default PATH and
> default man search path) but is "deprecated" by Freedesktop.

The distribution package manager and its packages have no business
installing anything there, so there is nothing to deprecate.  That the
default install add /usr/local/bin to PATH and similarly for other
directories is just a convenience.  Some of the BSDs do not do that
IIRC.

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

Icon pictures can be in /usr/local.  XDG desktop files (which make the
applications show up in the Gnome shell and other DEs) can be installed
in /etc/xdg, like the packages from the package manager do.  It is
possible that Gnome/XDG also looks into /usr/local/etc/xdg or some
similar place in addition to /etc/xdg, I haven't checked.

/etc is used both by distribution packages and by packages in
/usr/local.  Only distribution packages should install default
configurations there, and only if those files did not exist before or,
during an update, if they where not modified since installation or last
update.

When the user changes stuff in the desktop files (managing autostarts,
hiding applications), those changes go into copies of the files in
~/.local.  Gnome sees those files as overrides, as long as they have the
same name.  When the user installs applications for himself (e.g. using
xdg-desktop-icon), those desktop files also go there.

> to my knowledge, there is no default user directory for executables;

In some distibutions /etc/profile adds ~/bin to PATH, if it exists.
Again this is just a convenience.  In the end /etc is for the
administrator to set her/his own policy.

so long, benny
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

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.

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.


Such software should be installing to /opt, but might not.
 Installing application and configuration files in /opt is a 
possibility,
but what to do with man page, application launcher, entry in the 
application

menu? Installing in /opt does not require to mount /usr readonly. Just
create a particular user account for /opt and use it to install. 
Even one

user and one subdir per application.

Although I am not fully warmed up to /opt even after all of these
years for each of these questions there is a strategy to handle it.
PATH, MANPATH, desktop launcher files, and so forth.  But those are
all already set up for /usr/local by default.  /opt by the nature of
it being outside of the normal system then requires everything to be
set up for it.  Which is possible and easily done.  But then also must
be done if used.

 I have written such a software, called hopman. This 
discussion suggests
me that I should provide the option to install it in a user's 
directory,

without the need to be root, rather than install it system-wide.

I would say yes.  If it is intended to be installed outside of being
packaged for the system then it should be easily installed both by
root (or the classic group staff) in /usr/local or by the user as
non-root installed into the user's $HOME.

Back in 2019 Didier Kryn wrote:
 > cd hopman/hopman-1.0
 > make && make install # You must be root to install
 > Installed files: /usr/bin/hopman, ...

I didn't follow things beyond this so do not know how things evolved,
and it isn't fair of me to reach back into the original if it has
improved and evolved since then.  Sorry.  My bad.  But in the above it
really should install that into /usr/local/bin (or sbin) by default
instead of /usr/bin.

For my own environment I would run that as myself in group staff which
can write to /usr/local/bin without root.  I would run it.  It would
fail.  I would notice that it was trying to install into /usr/bin.  I
would review and inspect.  I would then make adjustments so that on my
system it installed into /usr/local.  Having a read-only /usr in order
to detect these issues by preventing them is useful.  In my case
readonly is achieved by not being root.  But since we are training a
new generation that one must be root for everything then mounting
/usr read-only kicks the can down the road and pushes the problem
around to a different place.  But root can always remount it
read-write.  And the arms conflict continues.  Is Qubes the logical
conclusion?

 https://www.qubes-os.org/

I also do not know the design of this particular tool hopman. It may
require by the nature of it an installation into the root file system
at the s

Re: [DNG] merged /usr breakage

[Didier Kryn]

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.

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.


Such software should be installing to /opt, but might not.

 Installing application and configuration files in /opt is a possibility,
but what to do with man page, application launcher, entry in the application
menu? Installing in /opt does not require to mount /usr readonly. Just
create a particular user account for /opt and use it to install. Even one
user and one subdir per application.

Although I am not fully warmed up to /opt even after all of these
years for each of these questions there is a strategy to handle it.
PATH, MANPATH, desktop launcher files, and so forth.  But those are
all already set up for /usr/local by default.  /opt by the nature of
it being outside of the normal system then requires everything to be
set up for it.  Which is possible and easily done.  But then also must
be done if used.


 I have written such a software, called hopman. This discussion suggests
me that I should provide the option to install it in a user's directory,
without the need to be root, rather than install it system-wide.

I would say yes.  If it is intended to be installed outside of being
packaged for the system then it should be easily installed both by
root (or the classic group staff) in /usr/local or by the user as
non-root installed into the user's $HOME.

Back in 2019 Didier Kryn wrote:
 > cd hopman/hopman-1.0
 > make && make install # You must be root to install
 > Installed files: /usr/bin/hopman, ...

I didn't follow things beyond this so do not know how things evolved,
and it isn't fair of me to reach back into the original if it has
improved and evolved since then.  Sorry.  My bad.  But in the above it
really should install that into /usr/local/bin (or sbin) by default
instead of /usr/bin.

For my own environment I would run that as myself in group staff which
can write to /usr/local/bin without root.  I would run it.  It would
fail.  I would notice that it was trying to install into /usr/bin.  I
would review and inspect.  I would then make adjustments so that on my
system it installed into /usr/local.  Having a read-only /usr in order
to detect these issues by preventing them is useful.  In my case
readonly is achieved by not being root.  But since we are training a
new generation that one must be root for everything then mounting
/usr read-only kicks the can down the road and pushes the problem
around to a different place.  But root can always remount it
read-write.  And the arms conflict continues.  Is Qubes the logical
conclusion?

 https://www.qubes-os.org/

I also do not know the design of this particular tool hopman.  It may
require by the nature of it an installation into the root file system
at the system level.  For example if it needs to run as a root 

Re: [DNG] merged /usr breakage

[Hendrik Boom]

On Thu, Jan 06, 2022 at 02:00:57PM -0700, Bob Proulx via Dng wrote:
> 
> > > > 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

Or even 

chown -R someresponsibleuser /usr/local

?

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Bob Proulx via Dng]

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.

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.

> > Such software should be installing to /opt, but might not.
>
> Installing application and configuration files in /opt is a possibility,
> but what to do with man page, application launcher, entry in the application
> menu? Installing in /opt does not require to mount /usr readonly. Just
> create a particular user account for /opt and use it to install. Even one
> user and one subdir per application.

Although I am not fully warmed up to /opt even after all of these
years for each of these questions there is a strategy to handle it.
PATH, MANPATH, desktop launcher files, and so forth.  But those are
all already set up for /usr/local by default.  /opt by the nature of
it being outside of the normal system then requires everything to be
set up for it.  Which is possible and easily done.  But then also must
be done if used.

> > > I have written such a software, called hopman. This discussion 
> > > suggests
> > > me that I should provide the option to install it in a user's directory,
> > > without the need to be root, rather than install it system-wide.

I would say yes.  If it is intended to be installed outside of being
packaged for the system then it should be easily installed both by
root (or the classic group staff) in /usr/local or by the user as
non-root installed into the user's $HOME.

Back in 2019 Didier Kryn wrote:
> cd hopman/hopman-1.0
> make && make install # You must be root to install 
> Installed files: /usr/bin/hopman, ...

I didn't follow things beyond this so do not know how things evolved,
and it isn't fair of me to reach back into the original if it has
improved and evolved since then.  Sorry.  My bad.  But in the above it
really should install that into /usr/local/bin (or sbin) by default
instead of /usr/bin.

For my own environment I would run that as myself in group staff which
can write to /usr/local/bin without root.  I would run it.  It would
fail.  I would notice that it was trying to install into /usr/bin.  I
would review and inspect.  I would then make adjustments so that on my
system it installed into /usr/local.  Having a read-only /usr in order
to detect these issues by preventing them is useful.  In my case
readonly is achieved by not being root.  But since we are training a
new generation that one must be root for everything then mounting
/usr read-only kicks the can down the road and pushes the problem
around to a different place.  But root can always remount it
read-write.  And the arms conflict continues.  Is Qubes the logical
conclusion?

https://www.qubes-os.org/

I also do not know the design of this particular tool hopman.  It may
require by the nature of it an installation into the root file system
at the system level.  For example if it needs to run as a root leve

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 05/01/2022 à 23:12, Hendrik Boom a écrit :

On Wed, Jan 05, 2022 at 09:54:20PM +0100, Didier Kryn wrote:

Le 05/01/2022 à 16:11, Hendrik Boom a écrit :

On Wed, Jan 05, 2022 at 12:08:18AM +0100, Didier Kryn wrote:

Le 04/01/2022 à 23:38, Hendrik Boom a écrit :

On Tue, Jan 04, 2022 at 05:09:58PM +0100, Didier Kryn wrote:

There is no utility in splitting the OS in several partitions.

Might it make sense to have /usr mounted readonly except when upgradng
or installing paackages?


    What could you fear which makes you want to keep /usr readonly.

software that isn't properly packaged as a .deb, but instead has an
"installer" that needs to be run as root.
    If the installer must be run as root, it is precisely because it 
needs

to install software in /usr. You have an alternative: either mount /usr
readwrite and install it, or keep /usr readonly and not install it. 
Keeping

/usr readonly and trying to install the software has no chance to work.


Such software should be installing to /opt, but might not.
    Installing application and configuration files in /opt is a 
possibility, but what to do with man page, application launcher, entry 
in the application menu? Installing in /opt does not require to mount 
/usr readonly. Just create a particular user account for /opt and use it 
to install. Even one user and one subdir per application.


    I have written such a software, called hopman. This discussion 
suggests

me that I should provide the option to install it in a user's directory,
without the need to be root, rather than install it system-wide.


software that is properly packaged, but has components that run as root
but do stuff with /usr outside my expectations.

    Do you mean a package from a Debian repository which would install a
trojan horse in /usr?
Packages from other sources that are built for Debian but aren't part 
of Debian.


    For these ones my personal attitude is binary: either I trust them 
or I don't, not half. Anyway, is there a difference wether the Trojan 
horse is in /usr or /opt ? Which matters is rather the permissions it 
has, then at first glance, creating an account per application seems a 
good practice.


--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Hendrik Boom]

On Wed, Jan 05, 2022 at 09:54:20PM +0100, Didier Kryn wrote:
> Le 05/01/2022 à 16:11, Hendrik Boom a écrit :
> > On Wed, Jan 05, 2022 at 12:08:18AM +0100, Didier Kryn wrote:
> > > Le 04/01/2022 à 23:38, Hendrik Boom a écrit :
> > > > On Tue, Jan 04, 2022 at 05:09:58PM +0100, Didier Kryn wrote:
> > > > > There is no utility in splitting the OS in several partitions.
> > > > Might it make sense to have /usr mounted readonly except when upgradng
> > > > or installing paackages?
> > > > 
> > >      What could you fear which makes you want to keep /usr readonly.
> > software that isn't properly packaged as a .deb, but instead has an
> > "installer" that needs to be run as root.
> 
>     If the installer must be run as root, it is precisely because it needs
> to install software in /usr. You have an alternative: either mount /usr
> readwrite and install it, or keep /usr readonly and not install it. Keeping
> /usr readonly and trying to install the software has no chance to work.


Such software should be installing to /opt, but might not.

> 
>     I have written such a software, called hopman. This discussion suggests
> me that I should provide the option to install it in a user's directory,
> without the need to be root, rather than install it system-wide.
> 
> > software that is properly packaged, but has components that run as root
> > but do stuff with /usr outside my expectations.
> 
>     Do you mean a package from a Debian repository which would install a
> trojan horse in /usr?

Packages from other sources that are built for Debian but aren't part of Debian.

-- hendrik

> 
> --     Didier
> 
> 
> ___
> 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

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 05/01/2022 à 16:11, Hendrik Boom a écrit :

On Wed, Jan 05, 2022 at 12:08:18AM +0100, Didier Kryn wrote:

Le 04/01/2022 à 23:38, Hendrik Boom a écrit :

On Tue, Jan 04, 2022 at 05:09:58PM +0100, Didier Kryn wrote:

There is no utility in splitting the OS in several partitions.

Might it make sense to have /usr mounted readonly except when upgradng
or installing paackages?


     What could you fear which makes you want to keep /usr readonly.

software that isn't properly packaged as a .deb, but instead has an
"installer" that needs to be run as root.


    If the installer must be run as root, it is precisely because it 
needs to install software in /usr. You have an alternative: either mount 
/usr readwrite and install it, or keep /usr readonly and not install it. 
Keeping /usr readonly and trying to install the software has no chance 
to work.


    I have written such a software, called hopman. This discussion 
suggests me that I should provide the option to install it in a user's 
directory, without the need to be root, rather than install it system-wide.



software that is properly packaged, but has components that run as root
but do stuff with /usr outside my expectations.


    Do you mean a package from a Debian repository which would install 
a trojan horse in /usr?


--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Hendrik Boom]

On Wed, Jan 05, 2022 at 12:08:18AM +0100, Didier Kryn wrote:
> Le 04/01/2022 à 23:38, Hendrik Boom a écrit :
> > On Tue, Jan 04, 2022 at 05:09:58PM +0100, Didier Kryn wrote:
> > > There is no utility in splitting the OS in several partitions.
> > Might it make sense to have /usr mounted readonly except when upgradng
> > or installing paackages?
> > 
>     What could you fear which makes you want to keep /usr readonly.

software that isn't properly packaged as a .deb, but instead has an 
"installer" that needs to be run as root. 

software that is properly packaged, but has components that run as root 
but do stuff with /usr outside my expectations.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[karl]

Aitor:
> On 4/1/22 22:17, k...@aspodata.se wrote:
> > the problem is that the lib is on a
> > filesystem that isn't available at kernel to init handover time.
> Did you try something like this:
> copy_exec /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0
> in a hook located at/usr/share/initramfs-tools, in order to include it in the 
> initrd? Sorry, 
> but i'm a bit unaware of the thread...

No, haven't tried it, don't use initrd, booting directly to disk.

Regards,
/Karl Hammar


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[aitor]

Hi Karl,

On 4/1/22 22:17, k...@aspodata.se wrote:

the problem is that the lib is on a
filesystem that isn't available at kernel to init handover time.


Did you try something like this:

copy_exec /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0

in a hook located at/usr/share/initramfs-tools, in order to include it in the initrd? Sorry, 
but i'm a bit unaware of the thread...


Cheers,

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 04/01/2022 à 23:38, Hendrik Boom a écrit :

On Tue, Jan 04, 2022 at 05:09:58PM +0100, Didier Kryn wrote:

There is no utility in splitting the OS in several partitions.

Might it make sense to have /usr mounted readonly except when upgradng
or installing paackages?

    What could you fear which makes you want to keep /usr readonly. If 
your OS is broken, you can reinstall it in a few hours. And the most 
likely thing which can break it is the package manager itself.


    Recently it happenned to me on Chimaera that some packages were 
broken, because of incompatible versions between backports and stable. I 
eventually solved the problem with the only help of Synaptic, and 
finally eliminated backports from sources.list. If necessary, I would 
just have re-installed Devuan without backports from the beginning.


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Hendrik Boom]

On Tue, Jan 04, 2022 at 05:09:58PM +0100, Didier Kryn wrote:
> There is no utility in splitting the OS in several partitions.

Might it make sense to have /usr mounted readonly except when upgradng 
or installing paackages?

-- hendrik

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[karl]

Antoine:
> On Monday,  3 January at 18:25, k...@aspodata.se wrote:
...
> >$ ldd /sbin/init | grep /usr
> >libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 
> > (0x7f737ba28000)
...
> Maybe your /etc/ld.so.cache is misconfigured?
...

What makes you believe that ?

ld.so.cache is just fine, the problem is that the lib is on a 
filesystem that isn't available at kernel to init handover time.
If I move over the lib to the root fs, then there is no problem
other than that apt/dpkg et al. don't know about it.

Regards,
/Karl Hammar


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Antoine via Dng]

On Monday,  3 January at 18:25, k...@aspodata.se wrote:

The first one gives me an unbootable system
$ ldd /sbin/init | grep /usr
   libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 
(0x7f737ba28000)

fortunately /bin/bash didn't depend on /usr so I could boot with
init=/bin/bash, but there is more breakage:

$ ldd /bin/mount | grep /usr
   libmount.so.1 => /usr/lib/x86_64-linux-gnu/libmount.so.1 
(0x7f5bc9b06000)
   libblkid.so.1 => /usr/lib/x86_64-linux-gnu/libblkid.so.1 
(0x7f5bc98f)
   libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 
(0x7f5bc982c000)

$ dpkg -l | grep sysvinit-core
ii  sysvinit-core2.96-7+devuan1 
amd64System-V-like init
$ dpkg -l | grep mount
ii  libmount1:amd64  2.36.1-8+devuan1   
amd64device mounting library
ii  mount2.36.1-8+devuan1   
amd64tools for mounting and manipulating filesystems

Soo, what can I do to help with that ?


Maybe your /etc/ld.so.cache is misconfigured?
Here's a little trick i discovered when I was learning to build initramfs 
files:


1. add the new /lib/ directories to /etc/ld.so.conf
2. run ldconfig to rebuild ld.so.cache
3. profit!

Hope this helps.

- Antoine

--
Any sufficiently advanced technology is indistinguishable from magic.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 04/01/2022 à 18:48, k...@aspodata.se a écrit :

Didier:

The simplest way to kick off problms with /usr merge is to *not*
make /usr a mountpoint.

Perhaps, but why break working systems, especially when they are
3h car ride from home and all in differnt locations.
That is just rude.


There is no utility in splitting the OS in several partitions.

...

My systems, my rules.

    I totally agree, "your system, your rules" (~: . And I fully agree 
that forcing the merge is at least impolite. I was just trying to 
de-dramatize the question. When some change prevents you to follow "your 
rules", the practical response is not to rant after the change (the 
merge) but first question the said rules.


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[karl]

Didier:
> The simplest way to kick off problms with /usr merge is to *not* 
> make /usr a mountpoint.

Perhaps, but why break working systems, especially when they are
3h car ride from home and all in differnt locations.
That is just rude.

> There is no utility in splitting the OS in several partitions.
...

My systems, my rules.

Regards,
/Karl Hammar


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Curtis Maurand via Dng]

> On Jan 4, 2022, at 11:10 AM, Didier Kryn  wrote:
> 
> The simplest way to kick off problms with /usr merge is to *not* make 
> /usr a mountpoint. There is no utility in splitting the OS in several 
> partitions. This wouldn't help you recover the OS if one partition is broken 
> since the package manager installs/deinstalls files not only on /usr, but 
> also /, /etc, /boot, /var. Splitting is even discouraged if you use a 
> filesystem with snapshots like btrfs (whih isn't my case). The only thing 
> which may (and should) be on a different disk (not partition) is the precious 
> user data, ie /home.
> 
> -- Didier

I simply save snapshots not only locally, but an external snapshots locally on 
a separate drive and to a NAS.

If my IQ were higher than the number of terabytes I have on the NAS, I would  
have the NAS in a separate location.

—Curtis

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

    The simplest way to kick off problms with /usr merge is to *not* 
make /usr a mountpoint. There is no utility in splitting the OS in 
several partitions. This wouldn't help you recover the OS if one 
partition is broken since the package manager installs/deinstalls files 
not only on /usr, but also /, /etc, /boot, /var. Splitting is even 
discouraged if you use a filesystem with snapshots like btrfs (whih 
isn't my case). The only thing which may (and should) be on a different 
disk (not partition) is the precious user data, ie /home.


--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[karl]

Ralph:
> On Mon,  3 Jan 2022 18:25:12 +0100 (CET)
> k...@aspodata.se wrote:
> >  The first one gives me an unbootable system
> > $ ldd /sbin/init | grep /usr
> > libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0
> > (0x7f737ba28000)
> > 
> >  fortunately /bin/bash didn't depend on /usr so I could boot with
> >  init=/bin/bash, but there is more breakage:
...
> No solution, but it looks like "the culprit" for this is that the
> libselinux1 package changed in between beowulf (buster) and chimaera
> (bullseye) from depending on libpcre3 to depending on libcre2-8-0.

libpcre3 was the old, and libcre2 the new lib, with -8 is for working on
8bit walues, also available is -16 and -32 (if you have wide 
characters).

> The former, libpcre3, installs its libraries in both /lib and /usr/lib
> (different), in both its beowulf and chimaera versions,  whereas
> libcre2-8-0 installs only in /usr/lib.

Yes, so it is:

/lib/x86_64-linux-gnu/libpcre.so.3.13.3
/usr/lib/x86_64-linux-gnu/libpcreposix.so.3.13.3
 vs.
/usr/lib/x86_64-linux-gnu/libpcre2-8.so.0.10.1

> I haven't reviewed the source for comment around that dependency
> change.

Apart from the strange numbering (which is upstreams fault),
the dependancy migration seems sane.

Regards,
/Karl Hammar

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Ralph Ronnquist via Dng]

On Mon,  3 Jan 2022 18:25:12 +0100 (CET)
k...@aspodata.se wrote:

>  The first one gives me an unbootable system
> $ ldd /sbin/init | grep /usr
> libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0
> (0x7f737ba28000)
> 
>  fortunately /bin/bash didn't depend on /usr so I could boot with
>  init=/bin/bash, but there is more breakage:
> 
> $ ldd /bin/mount | grep /usr
> libmount.so.1 => /usr/lib/x86_64-linux-gnu/libmount.so.1
> (0x7f5bc9b06000) libblkid.so.1 =>
> /usr/lib/x86_64-linux-gnu/libblkid.so.1 (0x7f5bc98f)
> libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0
> (0x7f5bc982c000)
> 
> $ dpkg -l | grep sysvinit-core
> ii  sysvinit-core2.96-7+devuan1
>   amd64System-V-like init $ dpkg -l | grep mount
> ii  libmount1:amd64  2.36.1-8+devuan1
>   amd64device mounting library ii  mount
>   2.36.1-8+devuan1   amd64
> tools for mounting and manipulating filesystems
> 

No solution, but it looks like "the culprit" for this is that the
libselinux1 package changed in between beowulf (buster) and chimaera
(bullseye) from depending on libpcre3 to depending on libcre2-8-0.

The former, libpcre3, installs its libraries in both /lib and /usr/lib
(different), in both its beowulf and chimaera versions,  whereas
libcre2-8-0 installs only in /usr/lib.

I haven't reviewed the source for comment around that dependency
change.

Ralph.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[karl]

Steve Litt:
> k...@aspodata.se said on Tue,  4 Jan 2022 00:08:01 +0100 (CET)
...
> >busybox can replace the mount command, but there is no fsck.* in
> >busybox.
> 
> Rather than fighting the mostly political fight of usr-merge,

If it makes systems unbootable it isn't a "political" fight.

> my first
> thought would be to make a whole new directory on the root partition.
...
> I'd probably call it /bb . Put all the static executables
> needed in early boot there. If there are a lot, it could have
> subdirectories,

We already have /bin and /sbin, there is no need to create a new one.

> and a bb.d subdirectory with scripts to be performed in
> order.

We already have one, /etc/rcS.d, which serves booting.

///

If you seriously want new directories for booting, somewhere
in /boot is more appropriate, it could possible replace initrd.

Regards,
/Karl Hammar

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Steve Litt]

k...@aspodata.se said on Tue,  4 Jan 2022 00:08:01 +0100 (CET)

>Karl:
>>  The first one gives me an unbootable system
>> $ ldd /sbin/init | grep /usr
>> libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0
>> (0x7f737ba28000)
>> 
>>  fortunately /bin/bash didn't depend on /usr so I could boot with
>>  init=/bin/bash, but there is more breakage:  
>...
>
>booting with init=/bin/bash and running the files /etc/rcS.d/S*
>manually it seems to be fsck.* and mount who has dependacies on /usr.
>
>To fix this, theese packages needs to un-/usr-merged:
> libmount1
> libblkid1
> libpcre2-8-0
> libuuid1
> uuid-dev
>
>busybox can replace the mount command, but there is no fsck.* in
>busybox.

Rather than fighting the mostly political fight of usr-merge, my first
thought would be to make a whole new directory on the root partition.
If you're looking for a name for this new directory, it could be:

/screw_freedesktop_poettering_and_redhat

Just kidding. I'd probably call it /bb . Put all the static executables
needed in early boot there. If there are a lot, it could have
subdirectories, and a bb.d subdirectory with scripts to be performed in
order. 

Of course, if you do this and it succeeds, freedesktop, poettering and
redhat will find ways to muck with it, so there may come a time when
defensive measures must be taken. But we can safely put this off until
later.

SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[karl]

Martin:
> k...@aspodata.se - 03.01.22, 18:25:12 CET:
> >  The first one gives me an unbootable system
> > $ ldd /sbin/init | grep /usr
> > libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0
> > (0x7f737ba28000)
> […]
> > Soo, what can I do to help with that ?
> https://manpages.debian.org/bullseye/dpkg/dpkg-fsys-usrunmess.8.de.html
> worked for me. No guarantees from my side.

 $ dpkg-fsys-usrunmess -n
 D: checking symlink? /bin
...
 System is fine, no aliased directories found, congrats!

Well, it is worse than that.

Regards,
/Karl Hammar

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Martin Steigerwald]

k...@aspodata.se - 03.01.22, 18:25:12 CET:
>  The first one gives me an unbootable system
> $ ldd /sbin/init | grep /usr
> libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0
> (0x7f737ba28000)
[…]
> Soo, what can I do to help with that ?

https://manpages.debian.org/bullseye/dpkg/dpkg-fsys-usrunmess.8.de.html

worked for me. No guarantees from my side.

see:

https://wiki.debian.org/Teams/Dpkg/MergedUsr

Best,
-- 
Martin


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[karl]

Karl:
>  The first one gives me an unbootable system
> $ ldd /sbin/init | grep /usr
> libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 
> (0x7f737ba28000)
> 
>  fortunately /bin/bash didn't depend on /usr so I could boot with
>  init=/bin/bash, but there is more breakage:
...

booting with init=/bin/bash and running the files /etc/rcS.d/S* manually
it seems to be fsck.* and mount who has dependacies on /usr.

To fix this, theese packages needs to un-/usr-merged:
 libmount1
 libblkid1
 libpcre2-8-0
 libuuid1
 uuid-dev

busybox can replace the mount command, but there is no fsck.* in
busybox.

Regards,
/Karl Hammar

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] merged /usr breakage

[karl]

 The first one gives me an unbootable system
$ ldd /sbin/init | grep /usr
libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 
(0x7f737ba28000)

 fortunately /bin/bash didn't depend on /usr so I could boot with
 init=/bin/bash, but there is more breakage:

$ ldd /bin/mount | grep /usr
libmount.so.1 => /usr/lib/x86_64-linux-gnu/libmount.so.1 
(0x7f5bc9b06000)
libblkid.so.1 => /usr/lib/x86_64-linux-gnu/libblkid.so.1 
(0x7f5bc98f)
libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 
(0x7f5bc982c000)

$ dpkg -l | grep sysvinit-core
ii  sysvinit-core2.96-7+devuan1 
amd64System-V-like init
$ dpkg -l | grep mount
ii  libmount1:amd64  2.36.1-8+devuan1   
amd64device mounting library
ii  mount2.36.1-8+devuan1   
amd64tools for mounting and manipulating filesystems

Soo, what can I do to help with that ?

Regards,
/Karl Hammar

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng