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

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 (gm...@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.

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

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

systemd-devel mailing list

Reply via email to