Re: systemd as external dependency

[Luca Ferretti <lferrett gnome org>]

Il giorno mer, 18/05/2011 alle 14.09 +0200, Lennart Poettering ha
scritto:

A really long list of questions, but I suppose I'll have to vote about
this proposal, so... 

> In the future I expect more interfacing with GNOME however, and I'd thus
> like to see the discussion regarding acceptance as blessed
> dependency started early.

Are you planning to "delegate" single module maintainers to implement
those interfaces? Do they agree on it? Do you have a list of involved
"core" modules (apart the ones listed below: gdm, gnome-session and
gnome-control-center)? 


> 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.

Reducing this to a yes-or-no-feature view: distro/kernels without
systemd will have to apply a (big?) patch gnome-control-center in order
to provide the ability to change locale and time settings. Is this
correct?

Also, if I haven't misunderstood, 'cause you will not maintain a systemd
version for non-linux kernels, if FreeBSD (just and example) will switch
to systemd, FreeBSD developers will have to maintain their own forked or
patched version of systemd, haven't they?


> - gdm will interface with the new CK-replacing code I am working on.
> 
>   http://lwn.net/Articles/441328/

Same previous yes-or-no question (to simplify: no systemd, no login),
plus I suppose this bond between systemd and gdm will add another -1 to
lightdm.


> - gnome-session will be augmented by a per-user systemd instace,
>   leveraging the benefits that systemd gives you for system startup also
>   for session startup.

You suggested to use #ifdef here, so I suppose we should be able to log
in and run GNOME even without systemd. 


> - Later on I hope that we can use per-application cgroups to create
>   reliable mapping between desktop files and processes. (i.e. place each
>   app in a cgroup and name it after the .desktop file), integrated into
>   the systemd cgroup hierarchy, so that this can be used for g-s and
>   other UIs to relate desktop files to processes.

Is this the only way to create a relationship between processes
and .desktop files? For example, another solution to this feature seems
to be BAMF (https://launchpad.net/bamf/  ), and I remember it was
suggested as a viable solution (maybe by vuntz?). Advantages?
Drawbacks? 

Do you think systemd approach will be used by or can be shared to
non-GNOME stuff too (for instance firefox or libreoffice or qt apps and
so on)?


> systemd is Linux-only. That means if we still care for those non-Linux
> platforms replacements have to be written. 

So, IIRC, the release team will have to choose between "have
features" (or enhancements to currently available features) and "create
a lockin" (or something that, at least currently, resembles a lockin).

Do you think we (release team) should follow a technical approach or a
"political" approach to this question? Why? 

We are still at 3.2 release and systemd is a young project and not
widely adopted solution. Any special reason to introduce this "lockin"
in GNOME now?
Isn't better to wait next releases and systemd maturity (read: a more
clear vision about systemd adoption in linux world and in non-linux
environments)? Do you have any plan to "sponsor" systemd outside linux
world (apart "here is the code, but I will not introduce your non-linux
stuff")?


> systemd itself has very minimal external dependencies. You need Linux,
> udev, D-Bus, and that's it. (there are a couple of additional optional
> deps however).

Could you please list those optional deps and explain how they are
useful?


> The first version i'd like to see blessed is systemd 26.

Do you have any plan about API/ABI/interface/other/whatever stability or
similar? How will a break effect GNOME modules?


Cheers and thanks in advance for your reply.