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.)
> 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.
> [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.
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).
How many packages will likely make use of this facility? Just systemd,
PAM, and D-BUS [1]? In my machine's /etc, I see roughly 200 configurations.
So, are we talking about a few packages or several hundreds?
Bruno
> > [0] https://0pointer.net/blog/projects/stateless.html
> > [1]
> > https://lists.gnu.org/archive/html/autoconf-patches/2023-02/msg00007.html
> > [2]
> > https://www.gnu.org/software/automake/manual/html_node/Hard_002dCoded-Install-Paths.html
> > [3]
> > https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/Package-Options.html
