[Top][All Lists]

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

Re: Add vendor configuration directory installation

From: Bruno Haible
Subject: Re: Add vendor configuration directory installation
Date: Fri, 10 Feb 2023 13:00:54 +0100

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

> 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

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.

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

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?


> > [0]
> > [1] 
> >
> > [2] 
> >
> > [3] 
> >

reply via email to

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