On 04/02/2014 08:06 AM, Daniel P. Berrange wrote:
>>
>> Rather than having a hardcoded choice of pm-utils vs systemd
>> I think we should check if the systemd service is running and
>> if so use it, otherwise fallback to pm-utils. That way if
>> someone has systemd installed, but is not running it as their
>> init, things would still work
>
> The idea is also to be able to drop the Requires: pm-utils in the spec
> file... so a runtime check wouldn't help this.
Oh, i mean you can still have WITH_PM_UTILS conditional in the RPM
spec / configure check. Downstream user can thus have the option to
have both enabled at build time, or to disable pm-utils and only rely
on systemd. ie we'd default to everything enabled and fully dynamic
at runtime, but we'd set the RPM builds to disable pm-utils on
Fedora >= 20
More or less this pseudo-code:
#if SYSTEMD && DBUS
try dbus calls; if successful return result
#endif
#if PM_UTILS
try pm-utils calls; if successful return result
#endif
return failure
and then it is possible for downstream to support both methods depending
on configure arguments. That way, the spec file can control configure
flags to create an ideal situation for Fedora (enforcesystemd only)
while avoiding bitrot for developers (developers can enable both systemd
and pm-utils code to make sure both branches compile)
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org