systemd system unit files and UsrMove

[Kay Sievers]

On Mon, Feb 20, 2012 at 13:51, Lennart Poettering <mzerqung at 0pointer.de> wrote:
> 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.

It's not a new exception, it's the reality for udev since ~6 years.

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

I second that.

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

That sounds right. And for the same reason, the udev rules need to
stay in lib/ and not move to share/.

Udev rules are not meant to be *shared* across anything, not across
different machines, not across architectures, not across multiple
packages. They only get installed _for_ the udev version that is the
primary architecture, and there can only be one udev version installed
on a system. The rules get installed by multiple packages, sure; but
they do not involve any, and must actually prevent any sort of
*sharing*.

The very same that is true for udev, is true for sytemd units. Rules
and units do not provide any additional or optional data, they
influence the actual global system runtime behaviour, they change and
extend the system, very much like a service plugin or a shared object.

That they are actually text file, is an implementation detail that
should not have influence on the installation directory.

Thanks,
Kay