External dependencies, DeviceKit-power and GNOME Power Manager

[Richard Hughes <hughsient gmail com>]

During the 2.25 release cycle I would like to move GNOME Power Manager
away from a HAL dependency and onto a new DeviceKit-power dependency.

DeviceKit-power is a new mechanism daemon that moves the battery
profiling and statistics interface system-wide, and also does the
history recording once per system, rather than once per session. It also
moves to an interface that is legacy-free and is more focused on the
entire power management system than HAL ever was.

You can see some screenshots of the new functionality on my blog:
http://blogs.gnome.org/hughsie/2008/11/09/gnome-power-manager-and-devicekit-power/
-- At the moment you have to compile with --enable-devicekit to get the
new functionality.

Q: Why is system wide better?
A: There's no point doing the data collection, statistics profiling and
calculations in every session on a multiuser workstation. There's also
the point that at GDM you run a g-p-m instance, which doesn't have
access to the profiling data you generate in the session, and so you get
"unknown time remaining".

Q: What's wrong with HAL?
A: HAL has grown into a mega-daemon doing a little bit of everything, it
evolved with DBUS over a number of years and is now pretty horrible
code. The DeviceKit set of daemons replace core functionality of HAL and
are developed by the very same maintainers as HAL was.
HAL also has a very low level interface, and so apps needed tons of
complicated code in the session to do simple things like work out
remaining battery lifetime.

Q: Is anything else going to use DeviceKit-$foo?
A: In the future gvfs will depend on DeviceKit-disks, not HAL

Q: Yet another system daemon?!?
A: No, all the DeviceKit daemons are system activated and low footprint,
so if you don't need them they don't get started.

Q: Can't you have --enable-hal and enable-devicekit in configure?
A: Not without a thousand #ifdefs, we would essentially have two
seporate engines which I don't want to support. I'm was trying to do
that on trunk and it's was getting crazy.

DeviceKit-power also implements a QoS (Quality of Service) interface for
latency control, and in the future will be used for _aggressive_
application power control. This is needed to produce a desktop that uses
little power when idle, but doesn't feel sluggish. There's more
information about this on my blog too.

What I propose is to switch trunk to using DeviceKit-power, and if
distros don't want to ship the very new code in 2.26.0, they can stick
with the old HAL only code of 2.24.x, like some distros last cycle did
with GDM. Of course, I'll still continue to actively maintain the 2.24
in parallel with the new development.

Switching to DeviceKit-power allows me to make g-p-m the simple session
process it should be, rather than the mess of legacy and complex code it
is now.

DeviceKit-power and DeviceKit-disks just depend on the trivial DeviceKit
daemon which is a thin dbus wrapper around udev.

So, comments please.

Richard.