[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Add vendor configuration directory installation

From: Jason Sikes
Subject: Re: Add vendor configuration directory installation
Date: Sat, 11 Feb 2023 21:00:26 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1

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


[4] curl -s

reply via email to

[Prev in Thread] Current Thread [Next in Thread]