Bug#727708: init system coupling etc.
* Russ Allbery (email@example.com) [140214 04:36]:
> Andreas Barth <firstname.lastname@example.org> writes:
> > * Russ Allbery (email@example.com) [140212 19:00]:
> >> Packages should normally support the default Linux init system. There
> > I would drop the word "Linux" here - Packages should support our default
> > init systems.
> That's a much stronger statement than we've made about support for the
> non-Linux ports in the past, where they're treated at most like another
> release architecture, which means that packages that have never worked on
> that architecture are not expected to do so and packages that used to work
> but stopped are sometimes removed from just that architecture rather than
> ported depending on the situation.
My expectation of packages is indeed that they work on as many
architectures as reasonable possible, and this includes that they
support the default init system there. (The question of "which
severity does a bug have" is a different question, for a release
architecture that bug would be serious according to
https://release.debian.org/jessie/rc_policy.txt section 4 paragraph 4
and I don't think we should lower the bar.)
I don't think that this expectation is wrong.
> >> are some exceptional cases where lack of support for the default
> >> init system may be appropriate, such as alternative init system
> >> implementations, special-use packages such as managers for
> >> non-default init systems, and cooperating groups of packages
> >> intended for use with non-default init systems. However, package
> >> maintainers should be aware that a requirement for a non-default
> >> init system will mean the package will be unusable for most Debian
> >> users and should normally be avoided.
> > Also, I would think it appropriate if packages should (i.e. in case
> > appropriate patches are available) support other init systems, and not
> > depend on the default init systems.
> I think that's already covered in the paragraph after this one.
If we agree on that, then we don't need to duplicate that.
> >> The Technical Committee offers no advice at this time on requirements
> >> or package dependencies on specific init systems after the jessie
> >> release. There are too many variables at this point to know what the
> >> correct course of action will be.
> > I think we could just drop the whole paragraph.
> Why do you want to drop it?
Because I currently don't see why we should say that (or: whats in
there which is not already said elsewhere), and in that case, less
text is better.