Re: Add vendor configuration directory installation

[Jason Sikes]

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.)
Aaaaaand 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=<path>: specify the path to search first for 
configuration files, but do not install there.

If we can do that with one parameter, that would be great. It was just 
easier for me to do it with two.

> 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 (there 
are a lot). So it's a little hairy.

--Thanks,

--Jason

> 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