Re: Add vendor configuration directory installation

[Jason Sikes]

On 2/10/23 06:15, Bruno Haible wrote:
> Alfred M. Szmidt wrote:
> > >     The configure --help output and/or the documentation should state that
> > >       - "make install" will install into SYSCONFDIR,
> > It should absolutley not state that.  It is on purpose that `make
> > install' does not trash sysconfdir
> Well, at least 178 packages do install files into sysconfdir.
> A search for sysconf_DATA in https://codesearch.debian.net shows you
> these packages [4].
I think the confusion on this point is that "make install" doesn't 
install EVERYTHING into SYSCONFDIR, just the configuration files.
> > if you install a program you do
> > not want your configuration files that you have modified to be
> > overwritten.
> Yes. And as far as I understand it:
>    - 178 packages violate this requirement,
>    - [0] is a proposal aimed at fulfilling this requirement.

I believe that the RPM package manager can check to see if a 
configuration file has changed, and, if so, save it with an ".rpmsave" 
extension before clobbering it with the new configuration file.

> Probably we also need to distinguish vendor installs (through the
> distro's package manager) and from-source installs (./configure &&
> make && make install).
I don't know if we should. I know this is another topic, but we 
packagers use "./configure, make, and make install" for just about all 
the packages we provide.
> > For configuration files that are "global" (which this
> > basically is); one should not use /usr/etc (which might not exist, or
> > point to /etc).  What should be used is /usr/share/PACKAGE or similar.
> But the vendors also want to make /usr "strictly read-only and fully
> cryptographically verified" [0]. AFAICS, the discussion here is about
> achieving three goals simultaneously:
>    - Installing or reinstalling a package should not overwrite the admin's
>      configuration files.
>    - The admin can create modified configuration files, based on those
>      shipped by the vendor.
>    - /usr should be read-only, even for the admin.
>
> A couple of things are not clear to me, though: If /usr is read-only, then
>    - How does the package manager install updates?

I don't know, and I'm interested to find out, too.

>    - How can the admin install packages from-source, with --prefix=/usr?
>    - What about /usr/local? Is it read-only as well? Thus the GNU default
>      prefix will become dysfunctional not only for the unprivileged user
>      but also for the admin user.

I really don't know as I haven't looked into any of these questions, but 
I'm curious as well.

I imagine (meaning: I don't know) that the people who want a read-only 
/usr directory are probably not interested in installing software that 
didn't come from their distributor.

I install software on my machine all the time. So I don't want to have 
any partition locked down like that.

> Bruno
>
> [0] https://0pointer.net/blog/projects/stateless.html
> [4] curl -s https://codesearch.debian.net/results/1d728e07eed9900a/packages.txt