* Russ Allbery (r...@debian.org) [140219 19:24]: > Andreas Barth <a...@ayous.org> writes: > > * Russ Allbery (r...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
