[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re-Proposal - preserve freedom of choice of init systems

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

Reply to: