Re: Add vendor configuration directory installation

[Jason Sikes]

On 2/7/23 15:44, Bruno Haible wrote:
> > On 2023-02-06 08:30, Valentin Lefebvre wrote:
> > >       This patch add a new autoconf argument that allows installation
> > > into the vendor configuration directory (/usr/etc/). Some linux
> > > distribution now move system configuration files from /etc to /usr/etc.
> > > See this ref: [0]....
> > > [0]https://0pointer.net/blog/projects/stateless.html
> I think that the proposed patch
>    * is a wrong means to a right goal,
>    * 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.

Aside from that nitpick, I agree with just about everything else you say 
here. So I am going to leave what you wrote intact.

> In detail:
>
>  From [0] and [1] I understand that the goal is:
>    * to have configuration created by the OS vendor under /usr/etc,
>      inside the read-only and possibly cryptographically secured /usr
>      hierarchy,
>    * to have configuration created by the administrator (user) under /etc,
>    * to have, in the code, a mechanism by which the configuration in /etc
>      overrides the configuration in /usr/etc. (At which level — the entire
>      configuration, or by file, or by configuration element — is not clear,
>      but is not relevant here.)
>
> So, a package's "make install" goal should only ever install in *one*
> of these two directories, namely
>    - in /usr/etc when the build is done on behalf of a distro,
>    - in $(prefix)/etc when the build is done on behalf of a user,
> never in /etc.
>
> The proposed patch "gives the opportunity for a project to install in both
> location /etc and /usr/etc in same time".[1]

I apologize for the confusion; in my understanding what you cited in [1] 
was not the intention of this proposal. You are correct that the 
configuration files should only go in one directory when done on behalf 
of a distribution.

And what you suggest later is much closer to what we are hoping for.

> This is not good because
>    - Installing in /usr/etc should be sufficient if the override mechanism
>      has been implemented.
>    - [PB2] Installing something in /etc would overwrite the administrator's
>      choices.
>    - [PB3] It invites the package's authors to look up certain files in /etc
>      (which is against one of the goals from [0] to be able to have a
>      system with an empty /etc) and other files in /usr/etc (which takes
>      away the freedom from the administrator to override the configuration,
>      if he can't write in /usr).
>
> The better solution is that:
>    - Packages install their configuration in $(sysconfdir). This is easily
>      done through Automake [2].
Yes!
>    - 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. So, for example, a user can install in their home 
directory or an admin can install in /opt.

Another big reason we don't use "prefix" is that we (packagers) already 
have macros that determine where various files should go (documentation 
goes here, executables go here, etc.). So using "prefix" would put a 
monkey wrench in all of that.

>    - 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.
>    - Packages implement the said override mechanism, looking first in
>      ETCDIR and then in SYSCONFDIR.

YES! Again, I apologize for the confusion; this is what we want.


Also, I should add that it doesn't help that my proposed nomenclature[4] 
is probably confusing. So maybe it's a good idea to change the name of 
the proposed new parameter? Might I suggest:

* RWCONFDIR,

* ALTCONFDIR, or

* ADMCONFDIR?

I guess no matter what we decide, the user will still need to look up 
documentation. I'm open to other ideas.


But yes, Bruno, what you have written is more of what we have in mind.

--Jason


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

> If we were to make it easy for packages to install in /etc, in addition to
> $(prefix)/etc, the problems PB2 and PB3 mentioned above are likely to occur.
>
> 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