systemd.eclass: use it in your packages!

Although systemd is not officially supported by Gentoo and it is not even in the tree yet, some of our packages already provide support for installing systemd units. This is because a few upstreams already supply and install systemd units in their packages.

I think it is important to support installing those units even before systemd is committed to gx86. This way, we can ensure users switching to systemd will have at least minimal working system without hacking packages around to get the necessary units. That’s why I’ve already committed the systemd.eclass.

My point here is that every package for which upstream officially supports systemd (and thus the configure script supports --with-systemdsystemunitdir) should use the systemd eclass. This way, we’re able to globally and universally control whether, where and how systemd units are installed.

Devs often refuse to use the eclass because it installs the units unconditionally. As I said earlier, and as I repeat now — that can be changed. Just take a part in the discussion that I tried to raise on the mailing list. The point of using the eclass is that we can change that and then have a way to let our users handle the change gracefully.

And please do not try to enforce your own conditionals on the eclass functions. Adding local USE=systemd is no solution. It just makes things harder for users for relatively small benefit.

2 thoughts on “systemd.eclass: use it in your packages!”

  1. What about packages that don’t have a configure script, but that would normally just install the systemd unit files unconditionally? Should there be an eclass function that returns what to do? I am specifically thinking of app-benchmarks/bootchart2, http://bugs.gentoo.org/show_bug.cgi?id=345695.

    1. That’s an interesting case indeed. AFAICS the package not only forces installing the systemd units but installs them in $(get_libdir) instead of /lib. I’d suggest either disabling auto-install of them (patching Makefile?) or moving them out of ${D}, and using systemd_dounit afterwards.

      The systemd_dounit is supposed to internally determine whether the unit files are supposed to be installed or not.

Leave a Reply

Your email address will not be published.