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 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141024122125.ga32...@bkor.dhs.org
