Quoting Daniel Kahn Gillmor (2014-10-17 18:38:35) > On 10/17/2014 12:06 PM, Ian Jackson wrote: >> And the GR text is quite careful: it doesn't say that failure to work >> with one init system is worse than any other bug. It is only >> _requiring a specific init system to be pid 1_ which is forbidden. > > If the requirement is testing a literal string match against > /proc/1/cmdline or $(readlink -f /sbin/init) or whatever, then that's > pretty silly, and surely that's *already* a bug that upstream would be > grateful for a fix. in this case, we don't need a GR. > > But if the requirement is "hey, i'm not going to work without > something else on the system performing functionality X", and a given > init system *doesn't provide* functionality X, then it sounds like > either a bug in the lacking initsystem (should provide functionality > X), or a straightforward case of an explicit dependency. It could > also be resolved by making some part of the dependent package's > functionality more limited in scope, and saying "we can run but we > can't to Y if we don't have access to system functionality X". These > are all legitimate options for resolving the problem, and they're > already available to folks who want to work on them today. It sounds > like the gdm issue was actually resolved already through some > combination of these approaches (thanks to Aigars for the recap > upthread). Why do we need a GR that's unlikely to change this > situation? We need the GR to ensure situation stays good. No big deal. > I'm going to stop commenting on this thread now and try to fix some > bugs that need fixing before the freeze. Me too :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature