On 09/11/14 at 14:42 +0100, Arno Töll wrote: > Hi, > > On 09.11.2014 13:36, Lucas Nussbaum wrote: > > With Choice 3, a package maintainer can decide to support only an init > > system that isn't the default if the maintainer considers it a > > prerequisite for its proper operation and no patches > > or other derived works exist in order to support other init systems > > in such a way to render software usable to the same extent. > > Yes. That being said, that's a hypothetical point you're making as we > (hopefully) all agree to > > a) appeal on maintainer's responsibility. I cannot imagine anyone > endorses a particular init system by deliberately excluding users of > other systems unless that would be really necessary for proper operation > and thus leaving no choice but doing so. Why do you think we need more > regulation for best practices that are known to work in Debian already? > We trust developers a lot for a reason.
"Proper operation" is not defined in the GR. What if other init systems provided degraded operation, resulting in bug reports from their users? We have had scenarios in Debian where maintainers, tired of receiving bug reports about problems on a specific architecture, decided to drop support for that architecture from their packages. Also, not "usable to the same extent" in the sufficient condition for the maintainer to drop support. > b) it appears that the current "default init system(tm)" is a superset > of other available alternatives, with the lowest common multiple being > sysvinit style scripts, which are supported by all packages that are > providing such start-up scripts, and will continue to do so. Not really. Some init systems (at least systemd and upstart) provide advanced features that are not available in any other init systems. If this proposal passes, I think that it would be fairly reasonable for upstreams or maintainers to start making more advanced uses of systemd service files, and at the same time, remove init scripts when it's not possible to alter them to match systemd service files functionality. > In practice choice 3 allows developers to take advantage of special > features available by the "default init system(tm)" as a last resort > when this is required by the package for proper operation. Yes, choice 3 > would also allow the use of "non-default init system(tm)" exclusive > features when no alternative way to achieve the same exists with the > "default init system(tm)", but really, what could that be, in practice? I agree that, in practice, the scenario of a package starting to require upstart-specific socket activation is unlikely. But given that we are having a GR about this, I think that it's important to not just think about the current state of things, but also look further about what it would mean in the more distant future. Lucas
signature.asc
Description: Digital signature
