Re: Re: Re-Proposal - preserve freedom of choice of init systems
On Sat, Oct 18, 2014 at 03:26:57AM +0100, Jonathan de Boyne Pollard wrote: > Perhaps if you picked something other than runit you'd make your point more > effectively. Try using the case of someone who makes a tool that depends > from System V init running as process #1. It is hardly farfetched. I've > seen at least two people publicly point out in the past several months that > they had something set up in /etc/inittab that broke when they switched to > an alternative bootstrap system. (A lot of people conflate "init" with > "rc". It's not System V init that other bootstrap systems sometimes provide > shims and compatibility mechanisms for. It's System V rc, more specifically > the /etc/rc?.d/* scripts that it runs.) There's also a Debian bug or two. > So the question that you should be asking to make your point is probably > this: The resolution says that "In general, software may not require a > specific init system to be pid 1.". Does this mean that softwares that make > use of /etc/inittab, which is peculiar to (in Ian Jackson's own words) "a > specific init system" (its contents, outwith sometimes the run level line, > being not processed at all by any of upstart, systemd, runit-init, > s6-svscan, the nosh system or service managers, minit, jinit, or finit), are > unfit for inclusion in Debian according to Ian Jackson's resolution? Yes, they almost certainly would be unfit for inclusion. Which is actually the status quo today, as inittab is a non-conffile config file with no management interface to permit additional packages to hook into it - making it a policy violation for other packages to edit this file. So I believe the requirements here are symmetric, and there's certainly no reason to think that the requirements are onerous because it would forbid integrating with /etc/inittab. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Re: Re-Proposal - preserve freedom of choice of init systems
Daniel Kahn Gillmor: The implication of this proposed GR seems to be that those tools > would be unfit for inclusion within debian unless someone erects all > the additional scaffolding that runit provides (process supervision, > pipelined logfiles with autorotation and log msgs just sent to > stderr, restart on abnormal termination, no need for daemonization, > clean process initialization, etc), but does so outside of runit. Ian Jackson: But runit is exactly the scaffolding needed to do that, and already > exists! runit can coexist peacefully with sysvinit, systemd, > upstart, or whatever. There is no problem depending on runit because > runit doesn't demand being pid 1, so it is nonexclusive. Daniel Kahn Gillmor: nevertheless, runit behaves differently when it is pid 1 than when > it is used in a subordinate role to another initsystem. If i'm > upstream and i'm building mechanisms that integrate with runit *as it > behaves as pid 1*, the implication seems to be that my work would not > be welcome in debian. Ian Jackson: Are you saying that a daemon author would want to write code which > only worked if runit was pid 1 ? Daniel Kahn Gillmor: Consider a tool that integrates in some way with /etc/runit/1 or > /etc/runit/2 or /etc/runit/3, which are only relevant for systems > with runit as pid 1 (see runit(8) for more details). Such a tool > should not be RC-buggy just because it's useless on a system that > uses systemd or sysvinit. Perhaps if you picked something other than runit you'd make your point more effectively. Try using the case of someone who makes a tool that depends from System V init running as process #1. It is hardly farfetched. I've seen at least two people publicly point out in the past several months that they had something set up in /etc/inittab that broke when they switched to an alternative bootstrap system. (A lot of people conflate "init" with "rc". It's not System V init that other bootstrap systems sometimes provide shims and compatibility mechanisms for. It's System V rc, more specifically the /etc/rc?.d/* scripts that it runs.) There's also a Debian bug or two. So the question that you should be asking to make your point is probably this: The resolution says that "In general, software may not require a specific init system to be pid 1.". Does this mean that softwares that make use of /etc/inittab, which is peculiar to (in Ian Jackson's own words) "a specific init system" (its contents, outwith sometimes the run level line, being not processed at all by any of upstart, systemd, runit-init, s6-svscan, the nosh system or service managers, minit, jinit, or finit), are unfit for inclusion in Debian according to Ian Jackson's resolution? * https://lists.debian.org/debian-vote/2014/03/msg00103.html * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747742 Requiring that people be bootstrap system neutral has perhaps unintended consequences, one of which is disappointing the spectators (in the press and on other mailing lists) who mistakenly thought that M. Jackson was championing the System V init status quo ante. Proper neutrality, it turns out once one sits down and actually looks at it, makes work for the maintainers of old softwares that only work with System V init, too. M. Jackson, perhaps unintentionally, is pushing in the final nail in the coffin of /etc/inittab . (-: -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5441cff1.4020...@ntlworld.com
Re: Re-Proposal - preserve freedom of choice of init systems
Quoting Daniel Kahn Gillmor (2014-10-17 18:38:35) > On 10/17/2014 12:06 PM, Ian Jackson wrote: >> And the GR text is quite careful: it doesn't say that failure to work >> with one init system is worse than any other bug. It is only >> _requiring a specific init system to be pid 1_ which is forbidden. > > If the requirement is testing a literal string match against > /proc/1/cmdline or $(readlink -f /sbin/init) or whatever, then that's > pretty silly, and surely that's *already* a bug that upstream would be > grateful for a fix. in this case, we don't need a GR. > > But if the requirement is "hey, i'm not going to work without > something else on the system performing functionality X", and a given > init system *doesn't provide* functionality X, then it sounds like > either a bug in the lacking initsystem (should provide functionality > X), or a straightforward case of an explicit dependency. It could > also be resolved by making some part of the dependent package's > functionality more limited in scope, and saying "we can run but we > can't to Y if we don't have access to system functionality X". These > are all legitimate options for resolving the problem, and they're > already available to folks who want to work on them today. It sounds > like the gdm issue was actually resolved already through some > combination of these approaches (thanks to Aigars for the recap > upthread). Why do we need a GR that's unlikely to change this > situation? We need the GR to ensure situation stays good. No big deal. > I'm going to stop commenting on this thread now and try to fix some > bugs that need fixing before the freeze. Me too :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Re-Proposal - preserve freedom of choice of init systems
On 10/17/2014 12:06 PM, Ian Jackson wrote:
> Daniel Kahn Gillmor writes ("Re: Re-Proposal - preserve freedom of choice of
> init systems"):
>> nevertheless, runit behaves differently when it is pid 1 than when it is
>> used in a subordinate role to another initsystem. If i'm upstream and
>> i'm building mechanisms that integrate with runit *as it behaves as pid
>> 1*, the implication seems to be that my work would not be welcome in debian.
>
> Are you saying that a daemon author would want to write code which
> only worked if runit was pid 1 ?
Consider a tool that integrates in some way with /etc/runit/1 or
/etc/runit/2 or /etc/runit/3, which are only relevant for systems with
runit as pid 1 (see runit(8) for more details). Such a tool should not
be RC-buggy just because it's useless on a system that uses systemd or
sysvinit.
> This question of daemon startup is a red herring, I think. It is
> generally easy to solve the problem with some kind of wrapper or tool,
> even if a daemon only starts up in a particular way.
so to be clear, it's not (and shouldn't be) an RC bug if a service fails
to start automatically on a system with a non-default init system, right?
>> I like both postgresql and runit, and am really happy that both these
>> things are in debian. But postgresql isn't RC-buggy just because the
>> system service doesn't start automatically when i choose to use runit as
>> pid 1.
>
> postgresql wouldn't be RC-buggy if it _never_ started automatically.
> That would just be an annoying bug.
I'm glad to hear that.
> And the GR text is quite careful: it doesn't say that failure to work
> with one init system is worse than any other bug. It is only
> _requiring a specific init system to be pid 1_ which is forbidden.
If the requirement is testing a literal string match against
/proc/1/cmdline or $(readlink -f /sbin/init) or whatever, then that's
pretty silly, and surely that's *already* a bug that upstream would be
grateful for a fix. in this case, we don't need a GR.
But if the requirement is "hey, i'm not going to work without something
else on the system performing functionality X", and a given init system
*doesn't provide* functionality X, then it sounds like either a bug in
the lacking initsystem (should provide functionality X), or a
straightforward case of an explicit dependency. It could also be
resolved by making some part of the dependent package's functionality
more limited in scope, and saying "we can run but we can't to Y if we
don't have access to system functionality X". These are all legitimate
options for resolving the problem, and they're already available to
folks who want to work on them today. It sounds like the gdm issue was
actually resolved already through some combination of these approaches
(thanks to Aigars for the recap upthread). Why do we need a GR that's
unlikely to change this situation?
> That's the exactly correct criterion because it is pid 1 which you can
> only have one of. A user can have as different non-pid-1 daemon
> supervisors as they like so there is no problem with a daemon
> requiring a particular supervisor - provided that supervisor can work
> (well enough) when not pid 1.
we also limit debian systems to only one mail-transport-agent (e.g. exim
or postfix or courier, but not two of them at once), but we don't say
that mta-specific packages are RC-buggy, even if someone who has a
courier installation would really like to use a tool that currently only
integrates into postfix's mail-handling flow.
I'm going to stop commenting on this thread now and try to fix some bugs
that need fixing before the freeze.
Ian, thanks for raising the concern, and Lucas, thanks for floating an
alternative option. I hope we can spend our limited time fixing
existing bugs and working well together.
--dkg
signature.asc
Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Daniel Kahn Gillmor writes ("Re: Re-Proposal - preserve freedom of choice of
init systems"):
> nevertheless, runit behaves differently when it is pid 1 than when it is
> used in a subordinate role to another initsystem. If i'm upstream and
> i'm building mechanisms that integrate with runit *as it behaves as pid
> 1*, the implication seems to be that my work would not be welcome in debian.
Are you saying that a daemon author would want to write code which
only worked if runit was pid 1 ?
This question of daemon startup is a red herring, I think. It is
generally easy to solve the problem with some kind of wrapper or tool,
even if a daemon only starts up in a particular way.
> I like both postgresql and runit, and am really happy that both these
> things are in debian. But postgresql isn't RC-buggy just because the
> system service doesn't start automatically when i choose to use runit as
> pid 1.
postgresql wouldn't be RC-buggy if it _never_ started automatically.
That would just be an annoying bug.
And the GR text is quite careful: it doesn't say that failure to work
with one init system is worse than any other bug. It is only
_requiring a specific init system to be pid 1_ which is forbidden.
That's the exactly correct criterion because it is pid 1 which you can
only have one of. A user can have as different non-pid-1 daemon
supervisors as they like so there is no problem with a daemon
requiring a particular supervisor - provided that supervisor can work
(well enough) when not pid 1.
Ian.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21569.15983.134642.422...@chiark.greenend.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
In linux.debian.vote Ian Jackson wrote: >If people want to make Debian derivatives that work only with a >particular init system, that's completely fine. The reverse - trying >to put back support for sysvinit, if it gets taken out of Debian, >would be very very difficult. As the upstream for our ecosystem, we >in Debian have a special responsibility to retain the flexibility our >downstreams might want. The only downstream distribution that choose to do this was Ubuntu, and they choose to stop using Upstart when it was not accepted as the default init system for Debian rather than keep trying to compete with systemd. Let's try to not conceive hypothetical problems just because you like their solution. -- ciao, Marco -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m1re4i$aoa$1...@posted-at.bofh.it
Re: Re-Proposal - preserve freedom of choice of init systems
On 10/17/2014 11:26 AM, Ian Jackson wrote:
> Daniel Kahn Gillmor writes ("Re: Re-Proposal - preserve freedom of choice of
> init systems"):
>> The implication here appears to be troubling for any upstream who wants
>> to rely on specific features of a given initsystem.
>
> Yes, indeed.
>
>> The implication of this proposed GR seems to be that those tools would
>> be unfit for inclusion within debian unless someone erects all the
>> additional scaffolding that runit provides (process supervision,
>> pipelined logfiles with autorotation and log msgs just sent to stderr,
>> restart on abnormal termination, no need for daemonization, clean
>> process initialization, etc), but does so outside of runit.
>
> But runit is exactly the scaffolding needed to do that, and already
> exists! runit can coexist peacefully with sysvinit, systemd, upstart,
> or whatever. There is no problem depending on runit because runit
> doesn't demand being pid 1, so it is nonexclusive.
nevertheless, runit behaves differently when it is pid 1 than when it is
used in a subordinate role to another initsystem. If i'm upstream and
i'm building mechanisms that integrate with runit *as it behaves as pid
1*, the implication seems to be that my work would not be welcome in debian.
>> This isn't surprising or specific to init systems, of course -- it's how
>> free software works.
>
> The problem with init systems is that you can have only one.
>
> If people want to make Debian derivatives that work only with a
> particular init system, that's completely fine. The reverse - trying
> to put back support for sysvinit, if it gets taken out of Debian,
> would be very very difficult.
i don't think that anyone has tried to remove support for sysvinit for
debian -- i certainly hope the sysvinit maintainers are unlikely to
leave the project or orphan the package. There may be packages that
don't work as well or integrate as well in a sysvinit-based debian
installation as they do for other choices of pid 1. But that is also
true if runit is my pid 1 -- some packages won't integrate as well with
my system if i choose this config. That doesn't mean those packages are
RC-buggy, it means i need to submit servicedirs for them and hopefully
find ways for developers to adopt them. Or to provide system service
packages that are distinct from packages containing the tools entirely
[0], so that anyone who wants to support service initialization on an
arbitrary initsystem can do so independently.
That said, i don't think that "putting back support for sysvinit" for
any given package that is unable to currently maintain it would actually
be as difficult as you make it out to be.
> As the upstream for our ecosystem, we
> in Debian have a special responsibility to retain the flexibility our
> downstreams might want.
Yes, we do. But we also have a responsibility to package and distribute
modern, upstream-maintained versions of useful free software even if
those versions have dependencies that some people might not find
preferable. We also shouldn't restrain packagers from uploading
software just because they don't have service initialization mechanisms
for every pid 1 that can possibly be used in a debian system.
I like both postgresql and runit, and am really happy that both these
things are in debian. But postgresql isn't RC-buggy just because the
system service doesn't start automatically when i choose to use runit as
pid 1.
Regards,
--dkg
[0] https://www.debian-administration.org/users/dkg/weblog/53
signature.asc
Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Daniel Kahn Gillmor writes ("Re: Re-Proposal - preserve freedom of choice of
init systems"):
> The implication here appears to be troubling for any upstream who wants
> to rely on specific features of a given initsystem.
Yes, indeed.
> The implication of this proposed GR seems to be that those tools would
> be unfit for inclusion within debian unless someone erects all the
> additional scaffolding that runit provides (process supervision,
> pipelined logfiles with autorotation and log msgs just sent to stderr,
> restart on abnormal termination, no need for daemonization, clean
> process initialization, etc), but does so outside of runit.
But runit is exactly the scaffolding needed to do that, and already
exists! runit can coexist peacefully with sysvinit, systemd, upstart,
or whatever. There is no problem depending on runit because runit
doesn't demand being pid 1, so it is nonexclusive.
> This isn't surprising or specific to init systems, of course -- it's how
> free software works.
The problem with init systems is that you can have only one.
If people want to make Debian derivatives that work only with a
particular init system, that's completely fine. The reverse - trying
to put back support for sysvinit, if it gets taken out of Debian,
would be very very difficult. As the upstream for our ecosystem, we
in Debian have a special responsibility to retain the flexibility our
downstreams might want.
Ian.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21569.13608.388043.939...@chiark.greenend.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
On 10/17/2014 10:33 AM, Ian Jackson wrote: > If the fix is not easy then we have three options: the release team > mark it `jessie-ignore', the GNOME maintainers fix it, or GNOME is > removed from jessie. The implication here appears to be troubling for any upstream who wants to rely on specific features of a given initsystem. As a developer, i've built tools that were deliberately minimal *because* i want those tools to rely on functionality provided by the initsystem of my choice. Concretely, i've built tools that work only when you have the runit package installed and functional as the local init system. The implication of this proposed GR seems to be that those tools would be unfit for inclusion within debian unless someone erects all the additional scaffolding that runit provides (process supervision, pipelined logfiles with autorotation and log msgs just sent to stderr, restart on abnormal termination, no need for daemonization, clean process initialization, etc), but does so outside of runit. I don't think this makes sense -- we should not be rejecting upstream packages from debian just because they are designed to take advantage of features of a given init system. I'm not opposed to helping people work within the confines of whatever init system they prefer -- one of the things i love about debian is that i've been able to run machines with runit as pid 1 for many years now. But i have always understood that if i'm not using the default initsystem, and something breaks from that interaction, i probably need to fix it myself (and to submit patches to upstream and/or the debian package if i want it to work better for other people who also use runit as pid 1). This isn't surprising or specific to init systems, of course -- it's how free software works. It sounds like there are a lot of people who care about making sure things work with sysvinit -- that's great, and i hope that energy will result in more functional sysvinit-based installations. I'm happy for us to maintain a healthy diversity, and want to see that work happen. But i don't think it is (or should be) an RC bug just because your particular package doesn't support my particular initsystem. --dkg signature.asc Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
Niels Thykier writes ("Re: Re-Proposal - preserve freedom of choice of init
systems"):
> While I appreciate that this is a very important issue for a lot of
> people, I am deeply concerned by the point in time it is revived.
> _*We have less than 3 weeks till the Jessie freeze starts!*_
I agree that the timing is very regrettable. You'd have to ask other
people why they didn't second the identical GR in March.
> Honestly, I am interpreting this as a ticking time bomb under the freeze.
>
> Who exactly is volunteering to implement this GR if it goes through?
> Taking GNOME as a hypothetical example[2], suppose it was uninstallable
> without systemd and the GNOME maintainers say "We do not want to
> implement this GR"[3].
That would depend how easy it would be to fix.
If the fix is easy (for example, the reason it's uninstallable is
because of a dependency declared for political reasons but without
which the actual operation is OK) then it would be a simple matter to
NMU it.
If the fix is not easy then we have three options: the release team
mark it `jessie-ignore', the GNOME maintainers fix it, or GNOME is
removed from jessie.
I mention the third option not because I think it's what we should do
right now, but to point out that I am not saying that the GNOME team
(or indeed GNOME upstream) have to do any work. No-one has to do any
work, but if the work goes undone, there are of course consequences to
the affected packages. If problems persist into jessie+1 I _would_
expect us to seriously consider removing GNOME.
> Then you leave us with a "per GR-defined RC buggy" default desktop from
> day one of the freeze and no one to clean it up.
Of course I would expect those choosing the default desktop to pick
one that wasn't RC-buggy.
> Be advised that I would very much be inclined to "jessie-ignore" such
> issues, if such stalemates end up as blockers for the release.
Would it help if we added a note to the GR explicitly saying that this
is what we expect ?
Something like:
Given the late passage of this resolution, we expect that
intractable bugs which are RC by virtue only of this resolution
will be tagged by the release team as `jessie-ignore'.
?
> Beyond that, I would /very much/ like to see guidelines for just "how
> much degradation" is "tolerable". Honestly, I think this should be a
> part of the GR text.
>
> I do not want to end up as "the bad guy" having to enforce this GR
> during the freeze, when I most at all really do not want this GR to
> affect Jessie at all.
I'm afraid that explaining guidelines for that seems obviously
impractical to me.
But the backstop is that uninstallability, or complete failure to work
on any system, is obviously RC. Lack of working power management or
broken suspend would be very annoying but probably not RC.
Ian.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21569.10430.534356.608...@chiark.greenend.org.uk
Re: Re-Proposal - preserve freedom of choice of init systems
On 2014-10-16 17:23, Ian Jackson wrote:
> Ian Jackson writes ("Re-Proposal - preserve freedom of choice of init
> systems"):
>> I wish to propose the following general resolution, and hereby call
>> for seconds. This GR resolution proposal is identical to that
>> proposed by Matthew Vernon in March:
>> https://lists.debian.org/debian-vote/2014/03/msg0.html
>> and the substantive text is that which was drafted for the purposes of
>> the technical committee's vote (where they decided not to pass a
>> resolution on the subject).
>>
>> IMO developments since March show that the concerns put forward then
>> were well-founded. Following discussions elsewhere including -devel I
>> have received enough offers of seconds by private email.
>
> I'm sorry to drag you into this now, but I don't want to end up
> perhaps passing a GR and then have an argument about its meaning.
>
Hi Ian,
While I appreciate that this is a very important issue for a lot of
people, I am deeply concerned by the point in time it is revived.
_*We have less than 3 weeks till the Jessie freeze starts!*_
Even if you got the DPL shorting the GR by 2 weeks[1], it is still
highly unlikely that the GR will be completed /prior/ to the freeze.
>> 2. Loose coupling of init systems
>>
>> [...]
>
> To make this a concrete example, the intent of this text is:
>
> The GR says that it would be a bug for GNOME not to be installable
> without systemd, even on Linux. Uninstallability would normally be an
> RC bug. The GR says that this uninstallability bug is not less severe
> just because it is limited to non-systemd setups. Therefore, GNOME
> depending on systemd is an RC bug.
>
> Is that how the release team would interpret these paragraphs of the
> GR ? If not, can you please suggest a clarification ? One option
> would be to include this clarification in the GR text as an example.
>
> Ian.
>
>
Honestly, I am interpreting this as a ticking time bomb under the freeze.
Who exactly is volunteering to implement this GR if it goes through?
Taking GNOME as a hypothetical example[2], suppose it was uninstallable
without systemd and the GNOME maintainers say "We do not want to
implement this GR"[3].
Then you leave us with a "per GR-defined RC buggy" default desktop from
day one of the freeze and no one to clean it up.
Be advised that I would very much be inclined to "jessie-ignore" such
issues, if such stalemates end up as blockers for the release.
Beyond that, I would /very much/ like to see guidelines for just "how
much degradation" is "tolerable". Honestly, I think this should be a
part of the GR text.
I do not want to end up as "the bad guy" having to enforce this GR
during the freeze, when I most at all really do not want this GR to
affect Jessie at all.
~Niels
[1] Which he can per §4.2.3 and §4.2.4.
[2] And a somewhat bad one since GNOME is actually is installable
without systemd per
https://lists.debian.org/debian-devel/2014/10/msg00412.html
[3] Which is their right per §2.1.1:
"""[...] A person who does not want to do a task which has been
delegated or assigned to them does not need to do it. [...]"""
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54402ee7.4020...@thykier.net
Re: Re-Proposal - preserve freedom of choice of init systems
Ian Jackson writes ("Re-Proposal - preserve freedom of choice of init systems"):
> I wish to propose the following general resolution, and hereby call
> for seconds. This GR resolution proposal is identical to that
> proposed by Matthew Vernon in March:
> https://lists.debian.org/debian-vote/2014/03/msg0.html
> and the substantive text is that which was drafted for the purposes of
> the technical committee's vote (where they decided not to pass a
> resolution on the subject).
>
> IMO developments since March show that the concerns put forward then
> were well-founded. Following discussions elsewhere including -devel I
> have received enough offers of seconds by private email.
I'm sorry to drag you into this now, but I don't want to end up
perhaps passing a GR and then have an argument about its meaning.
> 2. Loose coupling of init systems
>
> In general, software may not require a specific init system to be
> pid 1. The exceptions to this are as follows:
>
>* alternative init system implementations
>* special-use packages such as managers for init systems
>* cooperating groups of packages intended for use with specific init
> systems
>
> provided that these are not themselves required by other software
> whose main purpose is not the operation of a specific init system.
>
> Degraded operation with some init systems is tolerable, so long as
> the degradation is no worse than what the Debian project would
> consider a tolerable (non-RC) bug even if it were affecting all
> users. So the lack of support for a particular init system does not
> excuse a bug nor reduce its severity; but conversely, nor is a bug
> more serious simply because it is an incompatibility of some software
> with some init system(s).
To make this a concrete example, the intent of this text is:
The GR says that it would be a bug for GNOME not to be installable
without systemd, even on Linux. Uninstallability would normally be an
RC bug. The GR says that this uninstallability bug is not less severe
just because it is limited to non-systemd setups. Therefore, GNOME
depending on systemd is an RC bug.
Is that how the release team would interpret these paragraphs of the
GR ? If not, can you please suggest a clarification ? One option
would be to include this clarification in the GR text as an example.
Ian.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21567.58091.577863.677...@chiark.greenend.org.uk
