On 2/10/23 04:00, Bruno Haible wrote:
Jason Sikes wrote:
You are correct that the
configuration files should only go in one directory when done on behalf
of a distribution.
OK, this removes my biggest worry.
* worse, invites packages to (perhaps inadvertently) restrict user freedom.
Restricting user freedom is certainly not the intent of this proposal.
As a hacker and programmer, this is not something I am interested in for
my own personal use. If I was an admin of a system where security is
important, then, yes, I would be considering this.
Sorry for the misunderstanding: I meant that the distro would take away
freedom from the admin user (by making /usr read-only). The admin user
can control the non-privileged user anyway; there's no change in that area.
Anyway, you've blown away this worry.
- Distributors use --prefix=/usr and don't specify --sysconfdir, because
its default value $(prefix)/etc is already appropriate.
My understanding of the "prefix" option is that it for building
something that installs in the case that system rules prohibit
installing in root.
The --prefix option is also meant for use by root. --prefix=/usr makes
sense when the /usr partition is writable. --prefix=/usr in combination
with "make install DESTDIR=/tmp/staging" also makes sense when the /usr
partition is read-only and there are some other means for transferring
the contents of /tmp/staging/usr to /usr. (Whether this can trigger
warnings by future invocations of the package manager apt / rpm / dnf / ...
is an independent consideration.)
Aand I stand corrected. I just checked a few of the builds that I
did recently, and we use "--prefix=/usr" in our configure step of
building an RPM. Now I know.
Another big reason we don't use "prefix" is that we (packagers) already
have macros that determine where various files should go
Sure, if a packager has other means to collect the artifacts, a
"make install" step that depends on a --prefix option is not needed.
- Packages define a configure option for the /etc directory, e.g.
--enable-etcdir=/etc
through Autoconf [3].
Yes, and what we are proposing is that this option (by a different name)
will be included in Autoconf so that developers don't have to add it
manually.
The proposed patch [1] does more than that. Especially the documentation
change suggests that it's OK for the "make install" step to install files
in both /usr/etc and /etc. As you clarified above, this is not what is
desired.
The configure --help output and/or the documentation should state that
- "make install" will install into SYSCONFDIR,
- but the package will read from ETCDIR and then from SYSCONFDIR.
You are correct. We will fix that. Our goal is to move all the
configuration files in packages that we provide over to /usr/etc, and
have programs look in for those files in both /etc and /usr/etc.
[4] "sysconfdir" and "distconfdir" are what we use in SUSE packaging to
point to /etc and /usr/etc respectively. So I used them for this
proposal. The problem is that their meanings are different, and their
actual usage is swapped. So that was a terrible idea.
Yes, we can't change the meaning of "sysconfdir" (as a directory to
install into) or its name, so many years after it was introduced.
Might I suggest:
* RWCONFDIR,
* ALTCONFDIR, or
* ADMCONFDIR?
ADMINCONFDIR sounds good to me. I.e. the option's name would be
--adminconfdir.
Ha! That was what I actually originally came up with, but it didn't line
up with the other options so I shortened it. So I guess that's two
people who vote for it.
ALTCONFDIR is too much from the perspective of the vendor. From the
perspective of the administrator, /etc is the primary and /usr/etc
is the alternate configuration directory.
RWCONFDIR can be misunderstood because
- on some systems, both /usr/etc and /etc will be writable by root,
- non-privileged users cannot write in either location.
The documentation then should make clear that
- the package is then supposed to make the value of the --adminconfdir
option available to the program by defining a C macro ADMINCONFDIR:
E.g. in packages that use Automake:
AM_CPPFLAGS += -DADMINCONFDIR=\"$(adminconfdir)\"
- the package's code is then supposed to read from that location,
- but the package should not install any files into $(adminconfdir).
Yes!
In addition, I found that another parameter, "--with-adminconfdir", was
useful. The purpose of this parameter is to tell the package that it
should look in both places for the configuration files.
I had difficulty getting that to work with only one parameter. (Maybe
it's because I'm not as well-versed in Autoconf as I should be.)
So, the proposal is adding:
1. --with-adminconfdir: specify that the package should search for
config files in $adminconfdir before searching in $sysconfdir, and
2. --adminconfdir=: specify the path to search first for
configuration files, but do
