Re: Add vendor configuration directory installation

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

--Jason

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.
>>>>         --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 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:
>>>
>>> * 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 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,
>
> --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