Re: Tentative summary of the amendments
On Fri, Oct 24, 2014 at 12:57:49PM +0300, Aigars Mahinovs wrote:
> The root of the problem is coming from upstream not caring about
> alternative init systems. To take the logind case as an example - each
> of the dependencies from GDM to systemd make perfect sense in
> isolation. However, the end result (was) that GDM only worked with
> systemd almost by accident. No developer in that chain was compelled
> to run this under other init systems.
If something else should be possible, then provide something with the
same API. Systemd-shim does this. It is or was a little bit buggy, but
not up to GNOME to do that work (although very much appreciated). Note
that when GNOME decided on logind next to ConsoleKit, ConsoleKit was
already unmaintained for a while and logind did not rely on systemd.
Upstream and "not caring":
1. It would be great and very welcome to have alternative
implementations using the same API (not every logind thing needs to
be implemented AFAIK).
2. Not doing that work does not mean "not caring"
3. You can find a few individuals who don't care and voice that loudly.
At same time, we also have people going out of their way to assist.
[..]
> pushing such burdens to our users. That is too hard a punishment for
> using an alternative init system and also upstream (or maintainer) are
> far better positioned to implement some workaround to make the
> software work with alternative inits.
Why? Upstream are consumers of an API. This task should reside with
people who can write things like "systemd-shim". If nobody writes it,
unfortunate but seems indicative of lack of interest. This is pretty
much why this GR is so strange. For one, it is too vague. Secondly,
as upstream I'm fine with having a discussion on how to help each other.
In this case it hasn't happened despite me reaching out many times.
Moreover, the wrong upstream is expected to do work. As combined result,
this GR is not going to be actioned upstream.
> How to best formulate a rule that would make sure that happens is a
> good discussion to have. I myself prefer a requirement to support
> running with *both* default Debian init *and* sysvinit (as the
> canonical common shared init system API implementation).
Trying to force upstream to do this work is not going to get you far.
"Heading up the wrong tree", IMO.
--
Regards,
Olav
Reply to: