Re: Requiring systemd for the gnome-settings-daemon power plugin
- From: Colin Walters <walters verbum org>
- To: William Jon McCann <william jon mccann gmail com>
- Cc: Bastien, "desktop-devel-list gnome org" <desktop-devel-list gnome org>, Nocera <hadess hadess net>
- Subject: Re: Requiring systemd for the gnome-settings-daemon power plugin
- Date: Wed, 24 Oct 2012 11:28:45 -0400
On Wed, 2012-10-24 at 09:36 -0400, William Jon McCann wrote:
> I agree with you that we need to have a motive to change and that
> costs should be weighed carefully. We can make the case.
Yes. You've done some of that here. As we discussed on IRC, stuff like
having GNOME tightly integrated with the journal would be very
compelling.
> What is unwise, in my opinion, is ifdef'ing or branching the user
> experience to suit the code.
There is as you say below, a short term and a long term. Short term,
dealing with some ifdefs seems quite doable to me.
But for the medium term, we should gather a list of features that
depend on systemd. For each of those features, some of them can just
not exist if GNOME isn't compiled with systemd. Structured logging
probably falls into this category.
Others, like systemd-as-gnome-session, would clearly be a huge amount of
nontrivial duplication if we tried to support both. It's a
no-going-back type situation.
Really we're talking about 3 possible paths, in increasing order of
dependence/benefit:
1) No hard dep on systemd, maintain current CK bits to a greater or
lesser degree.
2) No hard dep on systemd, but delete CK bits.
3) Hard dep on systemd.
You are talking about 3). Bastien was trying to accomplish 2) (but the
current g-s-d code actually has a hard dep), and what I was going
for in the *short* term is to maintain the status quo of 1).
I'm not sure how much it makes sense though to spend a cycle or two
doing 2) if what we're *really* going for is 3).
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]