systemd system unit files and UsrMove

Kay Sievers kay.sievers at vrfy.org
Mon Feb 20 20:07:56 UTC 2012


On Mon, Feb 20, 2012 at 20:42, Nicolas Mailhot
<nicolas.mailhot at laposte.net> wrote:
>
> Le Lun 20 février 2012 18:50, Kay Sievers a écrit :
>> On Feb 20, 2012 6:25 PM, "Toshio Kuratomi" <a.badger at gmail.com> wrote:
>
>> Udev rules and systemd units belong to the installed daemon. This daemon
>> can only exist exactly one single time, and never be installed by multilib
>> packages, hence they do not ever belong into libdir.
>
> Actually, Udev rules and systemd units belong to the package that installed
> them. That's why hiding them in a private lib dir is wrong
>
> When amavisd instaciates clamav using the generic unit shipped with clamav but
> using an amavisd-specific conf file the clamav systemd unid is shared with
> amavisd
>
> That's why share is the natural place to share this arch-independant
> configuration and putting it in /usr/lib is grandfathering an exception that
> only existed because /share didn't exist

I couldn't disagree more.

/usr/share in our general understanding not to be used for
package-private things. There is no reason to have
/usr/share/<pkgdir>/ and /usr/lib/<pkgdir>, even LSB specifies that
only a _single_ dir should be used, hence the one in lib not in share.

Even the original distinction between arch-dependent and
arch-independent to support a share/ subdir that can be *shared*
between different machines will break with config like udev and
systemd in share/. This is not a *natural* place at all.

We tend to interpret /usr/share as something today, to place stuff
into that is really *shared* on the same host, like icons, man pages,
things that are mere a collection of similar stuff that multiple
packages use. It's definitely not a place to store system instructions
and system plugins.

Kay


More information about the devel mailing list