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. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org