Re: Add vendor configuration directory installation
Jason Sikes <[email protected]> Sat, 11 Feb 2023 21:00:26 -0800
| Newsgroups | gmane.comp.sysutils.autoconf.patches,gmane.comp.gnu.standards |
|---|---|
| Message-ID | <[email protected]> |
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 > > >