[systemd-devel] [ANNOUNCE] systemd v218

[Lennart Poettering]

On Fri, 12.12.14 14:25, Colin Guthrie (gmane at colin.guthr.ie) wrote:

> Lennart Poettering wrote on 11/12/14 00:16:
> >         * All systemd programs that read standalone configuration
> >           files in /etc now also support a corresponding series of
> >           .conf.d configuration directories in /etc/, /run/,
> >           /usr/local/lib/, /usr/lib/, and (if configured with
> >           --enable-split-usr) /lib/.  In particular, the following
> >           configuration files now have corresponding configuration
> >           directories: system.conf user.conf, logind.conf,
> >           journald.conf, sleep.conf, bootchart.conf, coredump.conf,
> >           resolved.conf, timesyncd.conf, journal-remote.conf, and
> >           journal-upload.conf.  Note that distributions should use the
> >           configuration directories in /usr/lib/; the directories in
> >           /etc/ are reserved for the system administrator.
> 
> Hmmm, at what point is /usr/local/lib/systemd/journald.conf.d/foo.conf read?
> 
> Does the journal start only after all local filesystems are mounted, I
> don't see anything that ensures this in the .service or .socket files
> for it (same applies to other tools, but journal is probably most at
> risk because it's started early with DefaultDependencies=no)
> 
> It feels very, very odd that /usr/local is being parsed at all here when
> the --prefix arg does not include it. I mean this kinda conflicts with
> users doing their own compiles with --prefix=/usr/local and installing
> stuff there... If the were experimenting, but ultimately didn't want to
> use it, it seems odd to me that the actual packaged version of system
> would read these files.
> 
> What's the argument for including /usr/local in all this stuff? Feels
> wrong to me.

Well, /usr/local has very unclear semantics. Installing something into
/usr/local if the stuff is never included in any search paths makes it
pretty useless.

The way I understand /usr/local, it is the place where the admin
himself places his own scripts and stuff, as extensions for the host
OS. Where /opt is the stuff for 3rd party apps (app vendors), and /usr
is for 2nd party stuff (OS vendor), /usr/local is for 1st party stuff
(admin).

The whole thing is really not thought to the end though. Some folks
have /usr/local on NFS, which we cannot handle, since we'll look into
it already before NFS is mounted for some things, and never check it
again...

Note that even though this is not thought to the end, the current
behaviour is perfectly in line with what the XDG basedir spec
suggests, which says that /usr/local should be included in the search
paths for things...

So far we always included it. I can see reasons to keep it that way, I
can see reasons way not including might also be a good
choice. Currently I don't see strong enough reasons to make the change
though.

Lennart

-- 
Lennart Poettering, Red Hat