systemd system unit files and UsrMove

[Lennart Poettering]

On Mon, 20.02.12 13:32, Nicolas Mailhot (nicolas.mailhot at laposte.net) wrote:

> 
> Le Lun 20 février 2012 13:02, Lennart Poettering a écrit :
> 
> > Something similar applies to udev rules and similar "almost code" bits.
> >
> > But yeah, I know people will disagree with us on this.
> 
> Lennart , you realise, do you, that people are unlikely to fix the historical
> exceptions they've benefited from as part of systemd or usrmove if you're
> championing the creation of new exceptions for your own sake in
> parallel.

This isn't really a "new" exception for me. There's a ton of files that
are not strictly arch dependent in bin, lib, libexec. Shell scripts,
Python scripts, udev rules, pkg-config files, a ton of rpm files, LSB
symlinks, Java files, Ruby files, yadda yadda yadda.

The thing is simply that there are cases where things are clear that
they belong on /lib, and others where it is clear that they belong in
/share. And then there is this huge grey area in the middle of those
files where things aren't super clear. The line between /lib and /share
is blurry. And since about always people then ended up coming to
different conclusions and hence dropped some stuff that you don't think
belongs in /lib into that very dir, and some stuff that others don't
think belongs in /share into that very dir. 

I think a rule of "if in doubt, /lib is preferable" is the safe choice
here though. In the case for unit files we have a couple of good reasons
to consider them arch-specific enough beyond just mere "if in
doubt". (see my earlier mail for them).

> Systemd unit files are no more cody and app-specific (and in fact quite a lot
> less) than emacs lisp files or java jar files or docbook xslt processing rules
> or a lot more stuff I'm forgetting about right now and those have been in
> /usr/share for a *long* time.

I see a ton of jar files in /usr/lib here actually.

The world isn't black and white. The separation between /share and /lib
is more complex than simple binary logic.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.