In some sense I am asking the same questions as Russ. Guillem Jover writes ("Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)"): > I've to say, that while I think I understand where your and other similar > reactions to this proposal are coming from, I also found them a bit > perplexing. :)
Let me skip to the end: > The key here, I guess, is that each situation needs to be evaluated > independently, and no magic decision tree will ever fix trying to work > things out with other people, in good faith, and trying to find > solutions or compromises that satisfy others and us too. But maybe this > is asking too much, dunno. :/ > > I understand that not giving apparently detailed guidance might make > things more difficult for the policy editors, and I'm sorry about that, > but I think no one ever expected that collaborating in a project such as > Debian with people pulling in random directions would always be easy? As you know I very much agree with you about the framing. But it appears that you don't that we should then, in something like your proposal, take the principles in that framing and apply them in to some of the most contentious specific problems facing us today. In its current state I think your proposal is unlikely to do well. I am very keen that something with your framing text should do well. Since you don't seem to agree that your option should be supplemented by specifics, I would like to ask the rest of the community: * Should I adopt Guillem's framing as a preamble to my own proposal ? (Should this be a new alternative or a replacement?) * Would Guillem's framing make a good preamble to Dmitry's option ? * Or do the supporters of Guillem's option favour some other combination of possible answers to the specific questions ? I think they key specific questions are: Q1 Init scripts. Possible answers, roughly: E Lack of an init script is an RC bug; maintainers must write init scripts. D Lack of an init script is not an RC bug but contributions of init scripts should be filed as RC bugs. Ie the non-systemd community must write them but maintainers must accept them. All other options  Lack of an init script is a normal or wishlist bug and maintainers can block them because they want systemd hegemony. Q2 sysusers.d, systemd timer units, etc. E May not be used (RC bug) unless a non-systemd-pid-1 implementation is available. Ie proponents of these interfaces must write the non-systemd variant. D Can be standardised in policy and used but only if they (i) are any good (ii) can sensibly exist for non-systemd. Ie, the non-systemd community must write the non-systemd variant, but they will get the time to do so. All other options  Everyone is allowed to use them willy-nilly and non-systemd support will rot. Q3 dependencies which cause init system switching etc. E,D Forbiddden All other options  Allowed. Theoretical degradations of dependencies on systemd systems will continue to make it really hard to install and maintain non-systemd ones. I have written this mail To people who seconded Guillem's proposal and to some people from the thread. I would particularly like to hear your views. I am considering making a formal variant of Guillem's proposal, which, if Guillem doesn't agree that specific guidance is needed, would stand on the ballot alongside Guillem's and my proposal D. I would like that proposal to reflect the views of people who seconded Guillem's proposal. Thanks Ian.  Sam's B "Support for multiple init systems is Important" appears to allow NMUs to provide init scripts and to use alternatives to systemd facilities but it says "According to the NMU guidelines". The NMU guidelines forbid NMUs when the maintainer has explicitly said they do not want a particular change. So in practice a maintainer who does not want an init script in their package can block this and the only possible recourse is to the TC, which is not suitable and not effective. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.