[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

| 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.


Reply to: