On Fri, Oct 24, 2014 at 04:02:24PM +0300, Aigars Mahinovs wrote: > That is not what is actually required. It is sufficient to handle the > situation when such functionality is not available. That is inside the
So in case functionality is not available in more than one init system, upstream cannot rely on that functionality. You're directing how the package should be developed, while not being part of the developers. Obviously you can have various requirements, but it has to make a bit of sense. Here, it's demanding something from the wrong group. As mentioned a few times before: open for discussion, demands like this are going to be ignored. If you'd read up, you'll notice that upstream does care and has done loads of work. I'd still summarize your rephrase as the same thing: realistically you're demanding the extra functionality to be done by upstream. You really get better results with assuming that as an upstream we do care instead of assuming the worst and being demanding. -- 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/20141024133209.gd32...@bkor.dhs.org
