I added CC to two more people who might be interested in what we are
discussing. I have also incorporated the suggestions you made and made
a second candidate patch, attached.
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
Restricting user freedom is certainly not the intent of this proposal.
As a hacker and programmer, this is not something I am interested in
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
Anyway, you've blown away this worry.
And again, I apologize for the confusion.
- Distributors use --prefix=/usr and don't specify
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.)
And I stand corrected. I just checked a few of the builds that I did
recently, and we indeed use "--prefix=/usr" in our configure step of
building an RPM.
Now I know.
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 for configuration files in both /etc and /usr/etc.
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.
Yes, and what we are proposing is that this option (by a different
- Packages define a configure option for the /etc directory, e.g.
through Autoconf .
will be included in Autoconf so that developers don't have to add it
The proposed patch  does more than that. Especially the documentation
change suggests that it's OK for the "make install" step to install
in both /usr/etc and /etc. As you clarified above, this is not what is
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.
 "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:
* ALTCONFDIR, or
ADMINCONFDIR sounds good to me. I.e. the option's name would be
Ha! That was what I actually originally came up with, but it didn't
line up with the other two options so I shortened it.
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
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 ? In my machine's /etc, I see roughly 200
So, are we talking about a few packages or several hundreds?
We are in the process of moving all of the packages that use /etc over
to /usr/etc. However, lots of packages that use /etc depend on other
packages that also use /etc, but we can't move them all at once.
--Again, thank you so much,