On Fri, 12.12.14 14:25, Colin Guthrie (gm...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
