Bug#727708: init system coupling etc.
* Russ Allbery (rra@debian.org) [140219 19:24]:
> Andreas Barth <aba@ayous.org> writes:
> > * Russ Allbery (rra@debian.org) [140214 04:36]:
>
> >> 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.
>
> That's a very good point.
>
> How does this sound to you?
>
> Packages should normally support the default init system on all
> architectures for which they are built. There 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.
Better but I think we should also point out that supporting different
architectures is a good thing.
So the first sentence rather as
| Packages should support as many architectures as reasonably possible,
| and they should normally ...
Also I'd like to amend the last sentence with ", and could constitute
an serious bug of the package." (which is a correct observation
according to the current RC policy)
> > 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.
>
> Given that the previous paragraph contains a lot of specific advice for
> the jessie release, I feel like it adds some clarity to say explicitly
> that we don't have advice to offer for the next release after jessie at
> this time.
Well, the paragraph cited above does apply not only to jessie (but
it's meaning could change depending on which architectures debian
supports in which way).
So I propose to change the text:
>
> 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.
to
| The Technical Committee offers no advice regarding sysvinit
| compatibility at this time after the jessie release. There are too
| many variables at this point to know what the correct course of action
| will be.
(the empty line above is there by purpose, i.e. it also merges this
paragraph with the previous one)
To avoid any doubt, this is a formal proposal for an amendment to
Russ's text, i.e. I would like to see it on the ballot.
I'll try to check my mail before 18:00 UTC but I cannot promise.
Andi
Reply to: