Upstream does supply a set of systemd unit files in the distribution tarball and an ability to control installation of those files through the --with/--without-systemdsystemunitdir option. The ebuild is currently unaware of these options, making installation of systemd units pkgconfig file dependant and thus automagic. The ebuild shall use systemd.eclass to handle installation of the systemd unit files in a clean and unified way. The preferred way to handle that is to use autotools-utils eclass, and call `systemd_to_myeconfargs' before `autotools-utils_src_configure', as in: inherit autotools-utils systemd src_configure() { local myeconfargs=( $(use_enable foo) --with-bar ) systemd_to_myeconfargs autotools-utils_src_configure } If you're not interested in migrating to autotools-utils, there is also a legacy `systemd_with_unitdir' function, which could be used like that: inherit systemd src_configure() { econf \ $(use_enable foo) \ --with-bar \ "$(systemd_with_unitdir)" } Currently introduction of the eclass will cause the package to install systemd unit files unconditionally. If you don't like that concept, feel free to take a vote on the appropriate gentoo-dev ml topic. The eclass behaviour might change in future.
Hi, If I understand your class and you comments correctly, changing ebuild would force it to always install systemd files, even on computers without systemd installed. I believe eclass should make sure systemd is installed in the first place before proceeding with any units installation.
(In reply to comment #1) > If I understand your class and you comments correctly, changing ebuild would > force it to always install systemd files, even on computers without systemd > installed. > I believe eclass should make sure systemd is installed in the first place > before proceeding with any units installation. As stated in the long message I pasted, this is not a place for this discussion. Eclass can be changed, while ebuilds randomly installing and not installing files are not a good idea.
Currently I do not see any advantage of using this eclass. While I understand that we need better way of handling unit files, current eclass implementation doesn't support necessary bits to justify ebuild porting. With current automagic behavior unit files are only installed when systemd is present.
(In reply to comment #3) > Currently I do not see any advantage of using this eclass. While I understand > that we need better way of handling unit files, current eclass implementation > doesn't support necessary bits to justify ebuild porting. > With current automagic behavior unit files are only installed when systemd is > present. Which implies that users migrating to systemd have to guess which packages would have installed such files and randomly rebuild them.
Pushed to the tree.
About the --with-systemdunitdir issue, I did some thinking and I'll probably add an optional argument to systemd_with_unitdir allowing to change the option name. This should be quite similar to what use_with provides.
Ok, I have added an optional argument to systemd_with_unitdir [1]. I'd appreciate if you could update connman ebuild to use it. [1]:http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/systemd.eclass?r1=1.3&r2=1.4
That's now done.
