Re: Tentative summary of the amendments
On Fri, 24 Oct 2014 10:21:01 +0200, Holger Levsen <holger@layer-acht.org> said:
> Hi Uoti, thanks for your summmary of the situation.
> On Donnerstag, 23. Oktober 2014, Uoti Urpala wrote:
>> In another mail, Ian said that his interpretation is that the init
>> system would not only have to be packaged in Debian, but in testing
>> and not RC buggy.
> yeah, I found this interpration also "interesting"... (eg. that there
> is room for interpretaion... I thought "in Debian" ment sid and could
> be buggy. Now I learn that buggy packages in sid seem to not always be
> part of Debian... at least not in the context of this amendment.) -
> interesting and a bit scary.
Apologies to Ian for opening yet another can of worms. I thought that
my request for clarification was for a fairly straightforward issue...
Without wanting to put any words into Ian's mouth, I believe the intent
is that any package can be installed with at least two init systems that
are supported by Debian. In particular, a user should not have to go
outside of the repository that they installed the package from. So if a
package foo in stable depends on init1 | init2 | ..., then at least two
of init1, init2, ... should be in stable.
How do packages get in stable? They must be in testing first, so Ian
saying that the alternative init system must be in testing seems
reasonable from the viewpoint of releasing stable. And if the init
system has an rc bug (that is not labelled *-ignore), then it won't make
it into stable either. So if an init system fails the conditions that
Ian gave, then it will not be in the next stable release.
I believe that what Ian is trying to avoid is the situation where
package foo depends on init1 | init2 | ... but only init1 is in testing,
and init2, ... are all in unstable and in no condition to be part of the
next release, and then we eventually release stable with only foo and
init1, but not init2 | ... Basically, you shouldn't be allowed to get
around the requirements of Ian's proposal by using some broken,
non-release-quality init system as your alternative; the alternative
init system must be something that users can actually use.
The wording that Ian used isn't what I would have used -- I would have
said that the alternative init system must be available from the same
(repository|distribution|Debian version) as the package the user wants
to install -- but I think the intent and the effect is pretty much the
same as what Ian said, especially when seen from the point of view of
stable.
--
Hubert Chathi <uhoreg@debian.org> -- Jabber: hubert@uhoreg.ca
PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/
Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA
Reply to: