[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Add vendor configuration directory installation

From: Jason Sikes
Subject: Re: Add vendor configuration directory installation
Date: Sun, 19 Feb 2023 23:29:56 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1

Hi All.

Here's another idea: instead of adding another parameter "adminconfdir", what do you think of enabling "sysconfdir" to take multiple, colon-separated paths? So if a user typed this:

$ ./configure --sysconfdir=A:B

Then the software package, if it supports this, could then:

1. install configuration files into the LAST directory in the pathspec, (in B), and

2. when reading the configuration, look for files in their given order (in this case: A then B).


On 2/16/23 04:26, Jason Sikes wrote:
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 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.
And again, I apologize for the confusion.

    - 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.)

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.

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.
      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
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

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 for configuration 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:



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 --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?

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,



[1] [2]

reply via email to

[Prev in Thread] Current Thread [Next in Thread]