Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
On Sun, Oct 6, 2019, 8:17 PM Sean Whitton wrote: > Hello, > > On Sat 05 Oct 2019 at 07:30PM -04, David Steele wrote: > > > I'm going to drop my objection, and assume that this is saying I don't > need to > > write init scripts for my special case. > > Okay -- perhaps you'd like to second Dmitry's patch, then, if you think > it reflects project consensus? > I'm abstaining. >
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
Hello, On Sat 05 Oct 2019 at 07:30PM -04, David Steele wrote: > I'm going to drop my objection, and assume that this is saying I don't need to > write init scripts for my special case. Okay -- perhaps you'd like to second Dmitry's patch, then, if you think it reflects project consensus? -- Sean Whitton signature.asc Description: PGP signature
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
On Sat, Oct 5, 2019 at 1:06 PM Sean Whitton wrote: > > Hello David, > > On Sun 29 Sep 2019 at 10:35AM -04, David Steele wrote: > > > On Sat, Sep 28, 2019 at 1:05 PM Sean Whitton > > wrote: > >> > >> Hello, > >> > >> On Sat 28 Sep 2019 at 04:18PM +00, Dmitry Bogatov wrote: > >> > >> > Reasonable. Then let's drop part about Depends: > >> > > >> > [ ... All packages with daemons must provide init.d scripts ...], > >> > unless software is only usable, by upstream's design, when > >> > pid1 is provided by some other init system. > >> > >> I think this would work. What do you think, David? > > > > I don't know. It provides more clarity the original Policy question, but > > raises > > a technical one I don't know the answer to. For my special case, is it > > practical to use systemd (via D-Bus) to manage system daemon > > start/stop when it is > > not pid1? If yes, things may have gotten worse (I'm responsible for getting > > this > > all to work correctly?). > > Unfortunately, there isn't quite enough context in your reply for me to > understand exactly how you think this makes things worse for you. Could > you expand, please? I'm going to drop my objection, and assume that this is saying I don't need to write init scripts for my special case.
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
Hello David, On Sun 29 Sep 2019 at 10:35AM -04, David Steele wrote: > On Sat, Sep 28, 2019 at 1:05 PM Sean Whitton wrote: >> >> Hello, >> >> On Sat 28 Sep 2019 at 04:18PM +00, Dmitry Bogatov wrote: >> >> > Reasonable. Then let's drop part about Depends: >> > >> > [ ... All packages with daemons must provide init.d scripts ...], >> > unless software is only usable, by upstream's design, when >> > pid1 is provided by some other init system. >> >> I think this would work. What do you think, David? > > I don't know. It provides more clarity the original Policy question, but > raises > a technical one I don't know the answer to. For my special case, is it > practical to use systemd (via D-Bus) to manage system daemon > start/stop when it is > not pid1? If yes, things may have gotten worse (I'm responsible for getting > this > all to work correctly?). Unfortunately, there isn't quite enough context in your reply for me to understand exactly how you think this makes things worse for you. Could you expand, please? > In that case I would prefer a statement discouraging systemd-specific > features. I doubt that we have project consensus on that. -- Sean Whitton signature.asc Description: PGP signature
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
Dmitry Bogatov writes: > --- a/policy/ch-opersys.rst > +++ b/policy/ch-opersys.rst > @@ -1006,7 +1006,9 @@ supported by all init implementations. An exception to > this rule is > scripts or jobs provided by the init implementation itself; such jobs > may be required for an implementation-specific equivalent of the > ``/etc/rcS.d/`` scripts and may not have a one-to-one correspondence > -with the init scripts. > +with the init scripts. Another exception is when software is only > +usable, by upstream's design, when pid1 is provided by some other init > +system. I don't believe this is a good solution as the list of exceptions would be cumbersome to maintain (cf. #911165). Ansgar
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
[2019-09-28 10:04] Sean Whitton > Hello, > > On Sat 28 Sep 2019 at 04:18PM +00, Dmitry Bogatov wrote: > > > Reasonable. Then let's drop part about Depends: > > > > [ ... All packages with daemons must provide init.d scripts ...], > > unless software is only usable, by upstream's design, when > > pid1 is provided by some other init system. > > I think this would work. What do you think, David? > > Dmitry, perhaps you could work up a patch against policy.git. From 629b6fd334806e5389e3cfee44997d95ac96501c Mon Sep 17 00:00:00 2001 From: Dmitry Bogatov Date: Sun, 29 Sep 2019 18:53:36 + Subject: [PATCH] Policy: Allow missing init.d script for services, specific to other init Wording: Dmitry Bogatov Closes: #932704 --- policy/ch-opersys.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst index 3e685cf..309d6fe 100644 --- a/policy/ch-opersys.rst +++ b/policy/ch-opersys.rst @@ -1006,7 +1006,9 @@ supported by all init implementations. An exception to this rule is scripts or jobs provided by the init implementation itself; such jobs may be required for an implementation-specific equivalent of the ``/etc/rcS.d/`` scripts and may not have a one-to-one correspondence -with the init scripts. +with the init scripts. Another exception is when software is only +usable, by upstream's design, when pid1 is provided by some other init +system. .. _s-upstart: -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
[2019-09-28 08:11] Sean Whitton > Hello, > > On Wed 25 Sep 2019 at 03:43PM +00, Dmitry Bogatov wrote: > > >> Candidate language attached. It adds "Also excepted are packages which > >> require a > >> feature of an alternate init system which is not available in SysV-Style > >> init systems.". Thoughts? > > > > Imho, it opens loophole. > > [...] > > Okay, so what we want to express here is the idea that there is an > exception for a package which uses a feature of systemd, where something > equivalent cannot be achieved by using a sysvinit script? Such as > something to access the systemd dbus interface. > > I'm not sure how to express that right now, but I think it can be done. I believe I proposed wording for this down in this thread. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
On Sat, Sep 28, 2019 at 1:05 PM Sean Whitton wrote: > > Hello, > > On Sat 28 Sep 2019 at 04:18PM +00, Dmitry Bogatov wrote: > > > Reasonable. Then let's drop part about Depends: > > > > [ ... All packages with daemons must provide init.d scripts ...], > > unless software is only usable, by upstream's design, when > > pid1 is provided by some other init system. > > I think this would work. What do you think, David? I don't know. It provides more clarity the original Policy question, but raises a technical one I don't know the answer to. For my special case, is it practical to use systemd (via D-Bus) to manage system daemon start/stop when it is not pid1? If yes, things may have gotten worse (I'm responsible for getting this all to work correctly?). In that case I would prefer a statement discouraging systemd-specific features.
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
Hello, On Sat 28 Sep 2019 at 04:18PM +00, Dmitry Bogatov wrote: > Reasonable. Then let's drop part about Depends: > > [ ... All packages with daemons must provide init.d scripts ...], > unless software is only usable, by upstream's design, when > pid1 is provided by some other init system. I think this would work. What do you think, David? Dmitry, perhaps you could work up a patch against policy.git. -- Sean Whitton signature.asc Description: PGP signature
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
[2019-09-26 17:48] Ansgar > On Thu, 2019-09-26 at 15:26 +, Dmitry Bogatov wrote: > > If this is the case, I'd propose wording like following: > > > > [ ... All packages with daemons must provide init.d scripts ...], > > unless software is only usable, by upstream's design, when pid1 is > > provided by some alternative init system. In such case, it must Depend > > on that alternative system (e.g binary package, that provides > > corresponding version of /sbin/init). > > Such a dependency shouldn't be added as one can run software in > containers or so and talk to the outside systemd instance. Note that > iptables doesn't depend on the linux kernel package either. Reasonable. Then let's drop part about Depends: [ ... All packages with daemons must provide init.d scripts ...], unless software is only usable, by upstream's design, when pid1 is provided by some other init system. > Also sysvinit would be an "alternative init system" given the current > default. As you wish. s/alternative/other/. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
Hello, On Wed 25 Sep 2019 at 02:33PM -04, David Steele wrote: > On Wed, Sep 25, 2019 at 2:00 PM Ansgar wrote: >> >> Well, the Policy Editors currently see no consensus; so to change it one >> would need to convince them, involve the tech-ctte or a GR. >> > > The Policy needs to either explicitly discourage the use of > systemd-specific features, or recognize the sysv-init incompatibility of > packages that use them, > > For my part, I have no interest in participating in the init wars. I just > want clear guidance on how to avoid an AUTORM-level bug report. > Right now the Policy is pretty much telling me to add an init script > with calls to systemctl. I'd like a different answer. I think we can achieve this. -- Sean Whitton signature.asc Description: PGP signature
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
Hello,
On Wed 25 Sep 2019 at 03:43PM +00, Dmitry Bogatov wrote:
>> Candidate language attached. It adds "Also excepted are packages which
>> require a
>> feature of an alternate init system which is not available in SysV-Style
>> init systems.". Thoughts?
>
> Imho, it opens loophole. Sysvinit does not provide equivalent of
> sd_notify("SD_READY=1"), so any service that links to libsystemd for
> that exactly call can be argued as "requiring feature [...] which is not
> available [...]".
>
> As real life example I recall Avahi-related bug (can't find number right
> now, sorry). Two inter-dependent services, where second fails to start
> unless first is already ready to listen.
>
> I'd argue this is bug in design, but if we consider design is written in
> stone, this is a bug in init.d script that must be worked around
> somehow.
>
> With your change in place, avahi maintainers would be able to drop
> sysvinit support instead of fixing init.d script.
>
> Very strong -1.
Okay, so what we want to express here is the idea that there is an
exception for a package which uses a feature of systemd, where something
equivalent cannot be achieved by using a sysvinit script? Such as
something to access the systemd dbus interface.
I'm not sure how to express that right now, but I think it can be done.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
Dmitry Bogatov writes: > This lintian check have number of false-positives, like `foo@.service` > files triggering complains about missing `/etc/init.d/foo@` scripts, That's not a false positive according to current policy. See also #911165. > and sometimes names plainly do not match (e.g bin:ifupdown). Neither is this. As I said before, the current requirements in policy aren't that helpful. Ansgar
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
On Thu, 2019-09-26 at 15:26 +, Dmitry Bogatov wrote: > If this is the case, I'd propose wording like following: > > [ ... All packages with daemons must provide init.d scripts ...], > unless software is only usable, by upstream's design, when pid1 is > provided by some alternative init system. In such case, it must Depend > on that alternative system (e.g binary package, that provides > corresponding version of /sbin/init). Such a dependency shouldn't be added as one can run software in containers or so and talk to the outside systemd instance. Note that iptables doesn't depend on the linux kernel package either. Also sysvinit would be an "alternative init system" given the current default. Ansgar
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
[2019-09-25 18:18] Ansgar > Practically the project seems to have already > decided that this is fine, even for packages that don't require > systemd: > > +--- > | There are 1033 non-overridden instances of lintian detecting a > | service unit without an init.d script [7]. > +---[ https://lists.debian.org/debian-devel-announce/2019/09/msg1.html ] I believe it partially my fault in this mis-representation. Yes, problem exists (and it is severe), but not as severe like 1033 out of 1300 daemons missing init.d scripts. This lintian check have number of false-positives, like `foo@.service` files triggering complains about missing `/etc/init.d/foo@` scripts, and sometimes names plainly do not match (e.g bin:ifupdown). -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
[2019-09-25 11:50] David Steele > On Wed, Sep 25, 2019 at 11:43 AM Dmitry Bogatov wrote: > > > > > > [2019-09-22 16:13] David Steele > > > Candidate language attached. It adds "Also excepted are packages which > > > require a > > > feature of an alternate init system which is not available in SysV-Style > > > init systems.". Thoughts? > > > > Imho, it opens loophole. > > [...]> > I'm just looking to avoid the scenario where I add systemctl calls to > an init script, for a package that uses the systemd D-Bus interface. > Alternate language is solicited. systemctl calls in init.d scripts? I do not understand. What software we are talking about? What does it mean "uses systemd D-Bus interface"? Does it mean that it can't do what it is supposed to do when pid1 != systemd? If this is the case, I'd propose wording like following: [ ... All packages with daemons must provide init.d scripts ...], unless software is only usable, by upstream's design, when pid1 is provided by some alternative init system. In such case, it must Depend on that alternative system (e.g binary package, that provides corresponding version of /sbin/init). -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
On Wed, Sep 25, 2019 at 2:00 PM Ansgar wrote: > > Well, the Policy Editors currently see no consensus; so to change it one > would need to convince them, involve the tech-ctte or a GR. > The Policy needs to either explicitly discourage the use of systemd-specific features, or recognize the sysv-init incompatibility of packages that use them, For my part, I have no interest in participating in the init wars. I just want clear guidance on how to avoid an AUTORM-level bug report. Right now the Policy is pretty much telling me to add an init script with calls to systemctl. I'd like a different answer.
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
On Wed, Sep 25, 2019 at 12:18 PM Ansgar wrote: > > Hi, > > On Sun, 2019-09-22 at 16:13 -0400, David Steele wrote: > > On Tue, Jul 23, 2019 at 2:10 PM Sean Whitton > > wrote: > > > The Policy Editors have decided that dropping the requirement to ship > > > init scripts is not something that can be decided by means of the Policy > > > Changes Process, at least for the time being. > > > > > > In proposing and reviewing wording to resolve this bug, then, we should > > > be careful not to weaken the requirement to ship init scripts. > > > Otherwise, in resolving this bug we would be changing the requirements > > > to ship init scripts by means of the Policy Changes Process. > > > > > > I'm suggesting this be kept in mind. It need not result in a wordier > > > change, and I certainly agree with you that we should assume good faith > > > on the part of package maintainers. > > > > > > > Candidate language attached. It adds "Also excepted are packages which > > require a > > feature of an alternate init system which is not available in SysV-Style > > init systems.". Thoughts? > > I don't think there is a way to get such changes through the policy > process as Sean said (I tried to document what I see as current > practice in #911165). Practically the project seems to have already > decided that this is fine, even for packages that don't require > systemd: > > +--- > | There are 1033 non-overridden instances of lintian detecting a > | service unit without an init.d script [7]. > +---[ https://lists.debian.org/debian-devel-announce/2019/09/msg1.html ] > > Ansgar > Regardless of the practicality, I'd like clarity on the policy. After reading #911165, I'd say I prefer it to this proposal. But something needs to be done about the current alternate init system support language.
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
David Steele writes: > On Wed, Sep 25, 2019 at 12:18 PM Ansgar wrote: >> I don't think there is a way to get such changes through the policy >> process as Sean said (I tried to document what I see as current >> practice in #911165). Practically the project seems to have already >> decided that this is fine, even for packages that don't require >> systemd: >> >> +--- >> | There are 1033 non-overridden instances of lintian detecting a >> | service unit without an init.d script [7]. >> +---[ https://lists.debian.org/debian-devel-announce/2019/09/msg1.html ] > > Regardless of the practicality, I'd like clarity on the policy. > > After reading #911165, I'd say I prefer it to this proposal. But something > needs to be done about the current alternate init system support > language. Well, the Policy Editors currently see no consensus; so to change it one would need to convince them, involve the tech-ctte or a GR. I have no intention to escalate this, but out of curiosity asked some people. From my understanding the ctte would prefer not having to deal with this (which I can understand given the default init discussion); I think this might also be true for Policy Editors. GRs are unpopular too. Ansgar
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
Hi, On Sun, 2019-09-22 at 16:13 -0400, David Steele wrote: > On Tue, Jul 23, 2019 at 2:10 PM Sean Whitton wrote: > > The Policy Editors have decided that dropping the requirement to ship > > init scripts is not something that can be decided by means of the Policy > > Changes Process, at least for the time being. > > > > In proposing and reviewing wording to resolve this bug, then, we should > > be careful not to weaken the requirement to ship init scripts. > > Otherwise, in resolving this bug we would be changing the requirements > > to ship init scripts by means of the Policy Changes Process. > > > > I'm suggesting this be kept in mind. It need not result in a wordier > > change, and I certainly agree with you that we should assume good faith > > on the part of package maintainers. > > > > Candidate language attached. It adds "Also excepted are packages which > require a > feature of an alternate init system which is not available in SysV-Style > init systems.". Thoughts? I don't think there is a way to get such changes through the policy process as Sean said (I tried to document what I see as current practice in #911165). Practically the project seems to have already decided that this is fine, even for packages that don't require systemd: +--- | There are 1033 non-overridden instances of lintian detecting a | service unit without an init.d script [7]. +---[ https://lists.debian.org/debian-devel-announce/2019/09/msg1.html ] Ansgar
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
On Wed, Sep 25, 2019 at 11:43 AM Dmitry Bogatov wrote:
>
>
> [2019-09-22 16:13] David Steele
> > Candidate language attached. It adds "Also excepted are packages which
> > require a
> > feature of an alternate init system which is not available in SysV-Style
> > init systems.". Thoughts?
>
> Imho, it opens loophole. Sysvinit does not provide equivalent of
> sd_notify("SD_READY=1"), so any service that links to libsystemd for
> that exactly call can be argued as "requiring feature [...] which is not
> available [...]".
>
> As real life example I recall Avahi-related bug (can't find number right
> now, sorry). Two inter-dependent services, where second fails to start
> unless first is already ready to listen.
>
> I'd argue this is bug in design, but if we consider design is written in
> stone, this is a bug in init.d script that must be worked around
> somehow.
>
> With your change in place, avahi maintainers would be able to drop
> sysvinit support instead of fixing init.d script.
>
> Very strong -1.
I'm just looking to avoid the scenario where I add systemctl calls to
an init script, for a package that uses the systemd D-Bus interface.
Alternate language is solicited.
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
[2019-09-22 16:13] David Steele
> On Tue, Jul 23, 2019 at 2:10 PM Sean Whitton wrote:
> >
> > The Policy Editors have decided that dropping the requirement to ship
> > init scripts is not something that can be decided by means of the Policy
> > Changes Process, at least for the time being.
> >
> > In proposing and reviewing wording to resolve this bug, then, we should
> > be careful not to weaken the requirement to ship init scripts.
> > Otherwise, in resolving this bug we would be changing the requirements
> > to ship init scripts by means of the Policy Changes Process.
> >
> > I'm suggesting this be kept in mind. It need not result in a wordier
> > change, and I certainly agree with you that we should assume good faith
> > on the part of package maintainers.
> >
>
> Candidate language attached. It adds "Also excepted are packages which
> require a
> feature of an alternate init system which is not available in SysV-Style
> init systems.". Thoughts?
Imho, it opens loophole. Sysvinit does not provide equivalent of
sd_notify("SD_READY=1"), so any service that links to libsystemd for
that exactly call can be argued as "requiring feature [...] which is not
available [...]".
As real life example I recall Avahi-related bug (can't find number right
now, sorry). Two inter-dependent services, where second fails to start
unless first is already ready to listen.
I'd argue this is bug in design, but if we consider design is written in
stone, this is a bug in init.d script that must be worked around
somehow.
With your change in place, avahi maintainers would be able to drop
sysvinit support instead of fixing init.d script.
Very strong -1.
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
On Tue, Jul 23, 2019 at 2:10 PM Sean Whitton wrote: > > The Policy Editors have decided that dropping the requirement to ship > init scripts is not something that can be decided by means of the Policy > Changes Process, at least for the time being. > > In proposing and reviewing wording to resolve this bug, then, we should > be careful not to weaken the requirement to ship init scripts. > Otherwise, in resolving this bug we would be changing the requirements > to ship init scripts by means of the Policy Changes Process. > > I'm suggesting this be kept in mind. It need not result in a wordier > change, and I certainly agree with you that we should assume good faith > on the part of package maintainers. > Candidate language attached. It adds "Also excepted are packages which require a feature of an alternate init system which is not available in SysV-Style init systems.". Thoughts? -- AE0D BF5A 92A5 ADE4 9481 BA6F 8A31 71EF 3661 50CE From 5b99099d370b6304cadaedc99d5f8d8cd3063c71 Mon Sep 17 00:00:00 2001 From: David Steele Date: Sun, 22 Sep 2019 15:53:12 -0400 Subject: [PATCH] Clarify exception to sysv init script requirement --- policy/ch-opersys.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst index 3e685cf..41f06fa 100644 --- a/policy/ch-opersys.rst +++ b/policy/ch-opersys.rst @@ -1006,7 +1006,9 @@ supported by all init implementations. An exception to this rule is scripts or jobs provided by the init implementation itself; such jobs may be required for an implementation-specific equivalent of the ``/etc/rcS.d/`` scripts and may not have a one-to-one correspondence -with the init scripts. +with the init scripts. Also excepted are packages which require a +feature of an alternate init system which is not available in SysV-Style +init systems. .. _s-upstart: -- 2.23.0
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
Hello David, On Tue 23 Jul 2019 at 12:49PM -04, David Steele wrote: > On Tue, Jul 23, 2019 at 11:15 AM Sean Whitton > wrote: >> >> I think that the wording for this change should reflect the above >> (unless I've misunderstood David), such that the new wording cannot be >> misinterpreted to mean that the sysvinit requirement does not apply to >> any package using any systemd component. > > That would resolve my issue, though I am not sold on the value of the > additional specificity. I'll say no more than this - If I am operating in good > faith, the additional language is not necessary. If I am not, it won't stop > me. Let me expand a bit. The Policy Editors have decided that dropping the requirement to ship init scripts is not something that can be decided by means of the Policy Changes Process, at least for the time being. In proposing and reviewing wording to resolve this bug, then, we should be careful not to weaken the requirement to ship init scripts. Otherwise, in resolving this bug we would be changing the requirements to ship init scripts by means of the Policy Changes Process. I'm suggesting this be kept in mind. It need not result in a wordier change, and I certainly agree with you that we should assume good faith on the part of package maintainers. Sorry for not writing this earlier in the thread and thank you again for filing this bug. -- Sean Whitton signature.asc Description: PGP signature
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
On Tue, Jul 23, 2019 at 11:15 AM Sean Whitton wrote: > > I think that the wording for this change should reflect the above > (unless I've misunderstood David), such that the new wording cannot be > misinterpreted to mean that the sysvinit requirement does not apply to > any package using any systemd component. That would resolve my issue, though I am not sold on the value of the additional specificity. I'll say no more than this - If I am operating in good faith, the additional language is not necessary. If I am not, it won't stop me. Dave
Bug#932704: Fwd: Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
Hello, On Mon 22 Jul 2019 at 10:15am -04, David Steele wrote: > The use of the systemd API blocks the work of those who don't like > systemd. Is that something that should that be addressed by Policy? I > don't think so. > > Under the scenario where the systemd api is used by a package, the > current Policy leads down a logical path resulting in vestigial init > scripts with calls to systemctl. Is that a preferred result, relative > to the proposed exception? > > I don't see how that ultimately meets anyone's goals for alternate init > support. Agreed, that's definitely not the preferred result. -- Sean Whitton
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
Hello, On Mon 22 Jul 2019 at 01:39pm +02, Ansgar wrote: > On Mon, 2019-07-22 at 12:01 +0100, Sean Whitton wrote: > > What sort of dependencies are we talking about? Package-level > dependencies (e.g. Depends: systemd-sysv directly or indirectly)? > >> People who don't like systemd have been working to provide replacements >> for these hard dependencies. E.g. there is elogind so that packages >> which depend on logind can work on a sysvinit system. >> >> We would want to be careful to word this requirement such that it did >> not license maintainers to do things which block the work of those who >> don't like systemd. > > How would this "block the work of those who don't like systemd"? > > We do not have a requirement to ship systemd .service units, but that > doesn't seem to have blocked anyone from submitting patches adding > those. It seems reasonable it would work the same for other init > systems. If a package depends on some systemd component which has been reimplemented not to depend on systemd (e.g. logind and elogind), it is my understanding of David's intent that this newly proposed exception would not apply. If the alternative implementation exists then the package does not depend on an alternative init system, and so the policy requirement to provide a sysvinit script remains in place. I think that the wording for this change should reflect the above (unless I've misunderstood David), such that the new wording cannot be misinterpreted to mean that the sysvinit requirement does not apply to any package using any systemd component. -- Sean Whitton
Bug#932704: Fwd: Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
Re-sending to the bug thread. -- Forwarded message - From: David Steele Date: Mon, Jul 22, 2019 at 9:15 AM Subject: Re: Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required To: Sean Whitton On Mon, Jul 22, 2019 at 7:02 AM Sean Whitton wrote: > > We would want to be careful to word this requirement such that it did > not license maintainers to do things which block the work of those who > don't like systemd. > > -- > Sean Whitton The use of the systemd API blocks the work of those who don't like systemd. Is that something that should that be addressed by Policy? I don't think so. Under the scenario where the systemd api is used by a package, the current Policy leads down a logical path resulting in vestigial init scripts with calls to systemctl. Is that a preferred result, relative to the proposed exception? I don't see how that ultimately meets anyone's goals for alternate init support. -- AE0D BF5A 92A5 ADE4 9481 BA6F 8A31 71EF 3661 50CE
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
On Mon, 22 Jul 2019 at 13:39:31 +0200, Ansgar wrote: > What sort of dependencies are we talking about? Package-level > dependencies (e.g. Depends: systemd-sysv directly or indirectly)? Probably yes. systemd-cron and dbus-user-session are examples of packages that rely on the systemd service manager being pid 1. Strictly speaking Depends: systemd-sysv is neither necessary nor sufficient to make the systemd manager pid 1 (a system without systemd-sysv could boot with init=/lib/systemd/systemd, or a system with systemd-sysv could boot with init=/some-other-init), so I used Depends: systemd, Recommends: systemd-sysv in dbus-user-session; but perhaps I should switch that to Depends: systemd-sysv, because it would make the intention clearer. smcv
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
On Mon, 2019-07-22 at 12:01 +0100, Sean Whitton wrote: > > "Also, SysV-style init scripts may be omitted for packages which have > > an explicit dependency on an alternate init system." What sort of dependencies are we talking about? Package-level dependencies (e.g. Depends: systemd-sysv directly or indirectly)? > People who don't like systemd have been working to provide replacements > for these hard dependencies. E.g. there is elogind so that packages > which depend on logind can work on a sysvinit system. > > We would want to be careful to word this requirement such that it did > not license maintainers to do things which block the work of those who > don't like systemd. How would this "block the work of those who don't like systemd"? We do not have a requirement to ship systemd .service units, but that doesn't seem to have blocked anyone from submitting patches adding those. It seems reasonable it would work the same for other init systems. Ansgar
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
Hello, On Sun 21 Jul 2019 at 08:46PM -04, David Steele wrote: > In section 9.11 (The Operating System/Alternate init systems), it is > stated that "...any package integrating with other init systems must > also be backwards-compatible with sysvinit by providing a SysV-style > init script...". There is a single exception for the alternate init > system implementation itself. > > There are other exception conditions that we may want to consider > here. For instance, if a package has an explicit dependency on a > particular "alternate" init system, to, say, access the systemd D-Bus > interface, there is likely little value in providing sysv init > scripts. > > I suggest that something like the following line be added to the end > of the second paragraph in that section: > > "Also, SysV-style init scripts may be omitted for packages which have > an explicit dependency on an alternate init system." People who don't like systemd have been working to provide replacements for these hard dependencies. E.g. there is elogind so that packages which depend on logind can work on a sysvinit system. We would want to be careful to word this requirement such that it did not license maintainers to do things which block the work of those who don't like systemd. -- Sean Whitton signature.asc Description: PGP signature
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
Source: debian-policy Version: 4.4.0.1 Severity: normal In section 9.11 (The Operating System/Alternate init systems), it is stated that "...any package integrating with other init systems must also be backwards-compatible with sysvinit by providing a SysV-style init script...". There is a single exception for the alternate init system implementation itself. There are other exception conditions that we may want to consider here. For instance, if a package has an explicit dependency on a particular "alternate" init system, to, say, access the systemd D-Bus interface, there is likely little value in providing sysv init scripts. I suggest that something like the following line be added to the end of the second paragraph in that section: "Also, SysV-style init scripts may be omitted for packages which have an explicit dependency on an alternate init system." -- AE0D BF5A 92A5 ADE4 9481 BA6F 8A31 71EF 3661 50CE
