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]. > 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. Probably we also need to distinguish vendor installs (through the distro's package manager) and from-source installs (./configure && make && make install). > 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? - 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. Bruno [0] https://0pointer.net/blog/projects/stateless.html [4] curl -s https://codesearch.debian.net/results/1d728e07eed9900a/packages.txt
