[systemd-devel] [ANNOUNCE] systemd v218

[Simon McVittie]

On 03/02/15 23:43, Lennart Poettering wrote:
> 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.

Yes, that view is consistent with the FHS (and e.g. Debian Policy's 
interpretation of the FHS). "./configure --prefix=/usr/local" is meant 
to "mostly work" for most software, which means it should be possible to 
hook into systemd, dbus-daemon, etc. by dropping files into /usr/local.

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

That's one version. Many OSs (including Debian and derivatives) have a 
slightly different interpretation where /usr is the system package 
manager's territory, regardless of whether the package came from Debian 
or not - things that came in a .deb go in /usr or occasionally /opt, 
while things that the sysadmin installed by hand go in /usr/local or 
occasionally /opt. Installing a .deb is allowed to have arbitrary 
effects on /usr (subject to the usual policies about not 
breaking/overwriting other packages without the metadata saying so), but 
the only thing it's allowed to do in /usr/local is to create/remove 
empty directories in the maintainer scripts.

 > On Fri, 12.12.14 14:25, Colin Guthrie (gmane at colin.guthr.ie) wrote:
 >> It feels very, very odd that /usr/local is being parsed at all here
 >> when the --prefix arg does not include it.

There's plenty of precedent for including /usr/local/bin in $PATH, 
/usr/local/share/FOO in search paths, etc., usually before /usr so that 
local sysadmin changes can override what's provided in the OS. This 
comes with the obvious caveat that if the local sysadmin breaks things 
by installing incompatible versions in /usr/local, they get to solve it 
for themselves.

The distinction between "modules installed in /usr/local for software 
also installed in /usr/local" and "modules installed in /usr/local for 
software installed in /usr" is not new either: in Debian and its 
derivatives, Python from python.deb looks for modules in 
.../dist-packages instead of the usual .../site-packages, so that 
.../site-packages can be reserved for modules that will be loaded into a 
copy of Python that the sysadmin installed from source.
<https://wiki.debian.org/Python#Deviations_from_upstream>

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

If they were experimenting with a new version of thermald (picking a 
random example of something that I have installed in /usr/local in the 
past), but systemd didn't pick it up, that would be a fairly useless 
experiment, since it wouldn't actually start :-)

If they were experimenting with it but decided not to keep it, that's a 
good time to remove it from /usr/local. Sysadmins who use /usr/local 
should really be looking at something like GNU stow to automate 
installation/removal (or preferably building their local stuff into a 
.deb/.rpm, at which point it can be in /usr instead).

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

I think "in general this should work, but your configuration is not a 
supported one" is an acceptable response to that, tbh. If a sysadmin 
wants this badly enough, they can put a hook in their initramfs to mount 
/usr/local.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>