[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: Fri, 10 Feb 2023 01:49:48 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1

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]....
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
   * 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
   - [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].
   - 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.
     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:




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.


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



reply via email to

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