Hi Luca, On 18/10/14 at 15:53 +0200, Luca Falavigna wrote: > Hi Lucas, > > Thank you for your feedback! > > 2014-10-18 14:13 GMT+02:00 Lucas Nussbaum <lu...@debian.org>: > > 1) packages may require the default init system if: > > - their maintainer consider this a prerequisite for its proper operation > > - no patches or other derived works exist in order to support other init > > systems > > > > 2) packages may require an init system other than the default init > > system if: > > - their maintainer consider this a prerequisite for its proper operation > > - no patches or other derived works exist in order to support other init > > systems, including the default init system > > > > These two cases are very different. > > I agree. I consider the first case the actual policy (or best practice, as > worst), and I'm still in favour of it. The second case tries to address the > cases where some packages will become immediately RC buggy because of a > change in the default init system. > > The following scenarios could happen if a change in the default init system > occurs anytime in Debian: > > The workflow without this proposal would be something like this. > * Maintainer is notified her software no longer works with the default init > * Maintainer looks how to support the default init (asking advice upstream, > welcoming patches from other contributors, writing patches herself, etc.) > * If nothing can be done, the package becomes unsuitable for a release, and > maintainer could be probably advised to ask for the removal of the software. > > The workflow after this proposal would be something like this: > * Maintainer is notified her software no longer works with the default init > * Maintainer looks how to support the default init (asking advice upstream, > welcoming patches from other contributors, writing patches herself, etc.) > * If nothing can be done, maintainer can inform users about the requirement > of a specific init system as PID 1, leaving users the freedom to switch > the default init system. This can be done by explicitly add a dependency > to a package which switches the default init system. > (Note that I consider out of scope for this proposal to discuss a method to > prevent an accidental change of default init system).
While I understand your concerns, I think that it is highly unlikely that we will decide to change the default init system to something that would break existing packages without a known reasonable way to fix them. > > (2) could lead to fragmentation in the services/init systems available in > > Debian, because it would no longer be the maintainers' responsibility to > > ensure that all packages work with the same init system. > > I still consider maintainers' responsibility to aim for maximum > standardization, including, but not limited to, the default init system > the software they package and distribute will run upon. > > As I stated in the Rationale paragraph: > "if [maintainers] consider [requiring a specific init system to run as PID 1] > necessary to prevent delivering broken, buggy, or otherwise incomplete > software" > maintainers could decide to strictly depend on a specific init system if there > is no possible way to avoid that (key word: *necessary*). > On the other hand, if solutions exist (#2), they could consider applying such > solutions, or being overruled by fellow developers (#3). Both: [...] if they consider it necessary to prevent delivering broken, buggy, or otherwise incomplete software packages and: to render software usable to the same extent are quite far-reaching criteria to allow maintainers to break standardization. I value standardization and integration very highly, and would be more comfortable (more likely to vote this above FD) with e.g.: On the other hand, Debian maintainers are fully entitled [...], if they consider it necessary to prevent delivering broken software packages, or software packages that would be unsuitable for a Debian release. and: ; and no patches or other derived works exist in order to support other init systems in such a way to render software basically usable. However, we can agree to disagree on the above. Thanks for the clarifications! Lucas -- 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/20141018154825.ga32...@xanadu.blop.info
