Re: systemd as external dependency
- From: Luca Ferretti <lferrett gnome org>
- To: Lennart Poettering <mztabzr 0pointer de>
- Cc: desktop-devel-list gnome org
- Subject: Re: systemd as external dependency
- Date: Thu, 19 May 2011 23:51:40 +0200
Il giorno mer, 18/05/2011 alle 14.09 +0200, Lennart Poettering ha
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
> 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
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.
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
> - 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?
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
> 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
> 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
> 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.
] [Thread Prev