On Tue, 2014-01-28 at 22:20 +0200, Adrian Bunk wrote: > On Tue, Jan 28, 2014 at 12:08:19PM -0800, Don Armstrong wrote: > > On Tue, 28 Jan 2014, Zbigniew Jędrzejewski-Szmek wrote: > > > On Tue, Jan 28, 2014 at 11:23:11AM -0800, Don Armstrong wrote: > > > > The former. So : > > > > > > > > Where feasible, software should interoperate with non-default init > > > > systems; maintainers are encouraged to accept technically sound > > > > patches to enable interoperation, even if it results in degraded > > > > operation while running under the non-default init. > > > > > > Maybe I'm dense... > > > > > > Scenario: Let's say that OpenRC is the new default init and in the > > > meanwhile, Gnome has gained a dependency on systemd. A patch to > > > support Upstart in Gnome is posted that partially breaks the > > > functionality under systemd. > > > > > > By your wording, maintainers are encouraged to accept the patch. > > > > No. This was precisely the ambiguity which Neil (correctly) pointed out. > > Simply put, patches which reduced existing functionality while running > > under the default init (say, systemd), would not be technically sound. > > > > Instead, maintainers are encouraged to accept the patch even if it > > results in reduced functionality while running under the non-default > > init (say, upstart) in comparison to the default init (say, systemd). > > That's a different case. > > Zbigniew was talking about a package that has a dependency on a > *non*default init system. > > And for that the first question is whether such a dependency on a > *non*default init would be allowed at all.
Not really. What Zbigniew was talking about was whether the above wording would allow a patch enabling operation with system A to degrade existing functionality with *another* system B (whether B is actually a strict "dependency" does not seem that important). This depends on how you interpret "the non-default init"; Don obviously meant this to refer to the same init as the patch is for. I think this kind of possible ambiguity could be avoided by phrasing like "even if the patch only implements a degraded mode of operation under this system", to make it clear that the "degrade" does not refer to any functionality that existed _before_ the patch. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
