Re: systemd as external dependency

[Federico Mena Quintero <federico ximian com>]

On Wed, 2011-05-18 at 14:09 +0200, Lennart Poettering wrote:

[setting the hostname and other little interfaces]
> In the long run I expect the following additional interfaces used by
> GNOME or one of its components:
> 
> - I am working on two more mechanisms generalizing control of the system
>   locale and system clock/timezone for use in the control center and by
>   other UIs.

A while ago, Rodrigo Moya had a lovely idea.  Back then we were
discussing the problem of distros having different mechanism for "stupid
little tasks which should be uncontroversial", like the hostname,
timezone, etc.

The plan was to introduce D-Bus interfaces to frob these things, and
then to cunningly provide an AdminKit with implementations of the
corresponding services.  Distros would realize, "oh, hey, we can use
this pre-made code instead of maintaining our own hacks - let's do
that".  And then AdminKit would be a de-facto standard interface and
unicorns would excrete rainbows.  Recalcitrant systems would be de-facto
forced to implement those D-Bus interfaces however they please.

Your idea, of course, is the same - except that it puts the services in
systemd (maybe not systemd itself, but the systemd package).  You need
somewhere to put them, after all.

There are *probably* hit-and-run services like "set the hostname" where
D-Bus activation could launch a tiny helper process that changes the
hostname and emits a signal, and dies quickly.  These present no
problem, except for how to ship them.

There are *probably* services that need to be running constantly, but I
can't think of one right now.  Those need a daemon.  I'm kind of unhappy
of the proliferation of daemons that we had at one point -
gnome-session, the user's D-Bus daemon, gnome-settings-daemon, etc.
Maybe if we had One Standard Way of loading service-y things into a
central daemon, we could save a little memory and context switches?  Is
this even worthwhile?  (If one crashes, it would make things much
worse...).

Maybe putting your services in an AdminKit would make things more
palatable to unenlightened^H^H^H^Htraditionalist systems that don't want
to use systemd just yet?

(Note: I don't care much where the services are shipped.  But putting
them in neutral ground may be better/easier in the medium term.)

  Federico