systemd system unit files and UsrMove

Kay Sievers kay.sievers at vrfy.org
Mon Feb 20 17:50:35 UTC 2012


On Feb 20, 2012 6:25 PM, "Toshio Kuratomi" <a.badger at gmail.com> wrote:

> This sounds like the unit files belong in %{_libdir} now?  However, that
> would mean that they can't go into noarch packages.  So we probably need
to
> know a little more about just how architecture dependent these unit files
> can be.

There is some serious confusion going on here with Fedora and libexec, not
only regarding the lib/ vs share/ problem.

The recommended defaults as mentioned in the packaging guidelines are just
plain wrong. The recent bug we opened regarding this was just closed
wontfix.

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. We support compat arch
only, not multiarch. Multiarch would look completely different anyway, and
compat arch does not need or want to involve libdir here.

The rules and units belong in 'libexecdir' which is upstream, and by LSB,
called and defined as /usr/lib/<pkgname>. Putting anything like that into
libdir is just wrong.

What the Fedora guidlines recommend here is not only wrong, it is also
playing bad with upstream, and as mentioned in the bug, I personally
consider it upstream-unfriendly, upstream-ignorant and against all common
sense in reducing the Linux distro balcanization, and just a bad example
how not to package tools today.

Please stop recommending or installing tools or other non shared objects in
libdir, they almost never belong there. I can see that a few exceptions can
be granted here, because it makes it easier to support binaries, that are
actually exclusively and directly bundled with a shared object, but
everything else just does not belong into libdir.

Thanks,
Kay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120220/ec9973b4/attachment.html>


More information about the devel mailing list