Re: [draft] Draft text on Init Systems GR

[Thomas Goirand]

On 11/19/19 7:29 PM, Ian Jackson wrote:
> Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
>> Ian Jackson  writes:
>>> Please do formally propose it and I will give my formal blessing to it.
> 
>> If I understand the process correctly, that looks like this:
> 
>> I propose that point 7 of Iam's seconded proposal be replaced with point 7
>> as shown here:
> 
> I accept this amendment.  The amended version should replace my
> proposal.  For completeness, I enclose it.  (My ref e8942d8c.)
> 
> Thanks,
> Ian.
> 
> -8<-
> 
> Title: Support non-systemd systems, without blocking progress
> 
> PRINCIPLES
> 
> 1. We wish to continue to support multiple init systems for the
>foreseeable future.  And we want to improve our systemd support.
>We are disappointed that this has had to involve another GR.
> 
> 2. It is primarily for the communities in each software ecosystem to
>maintain and develop their respective software - but with the
>active support of other maintainers and gatekeepers where needed.
> 
> SYSTEMD DEPENDENCIES
> 
> 3. Ideally, packages should should be fully functional with all init
>systems.  This means (for example) that daemons should ship
>traditional init scripts, or use other mechanisms to ensure that
>they are started without systemd.  It also means that desktop
>software should be installable, and ideally fully functional,
>without systemd.
> 
> 4. So failing to support non-systemd systems, where no such support is
>available, is a bug.  But it is *not* a release-critical bug.
>Whether the requirement for systemd is recorded as a formal bug in
>the Debian bug system, when no patches are available, is up to the
>maintainer.
> 
> 5. When a package has reduced functionality without systemd, this
>should not generally be documented as a (direct or indirect)
>Depends or Recommends on systemd-sysv.  This is because with such
>dependencies, installing such a package can attempt to switch the
>init system, which is not the what the user wanted.  For example, a
>daemon with only a systemd unit file script should still be
>installable on a non-systemd system, since it could be started
>manually.
> 
>One consequence of this is that on non-systemd systems it may be
>possible to install software which will not work, or not work
>properly, because of an undeclared dependency on systemd.  This is
>unfortunate but trying to switch the user's init system is worse.
>We hope that better technical approaches can be developed to
>address this.
> 
> 6. We recognise that some maintainers find init scripts a burden and
>we hope that the community is able to find ways to make it easier
>to add support for non-default init systems.  Discussions about the
>design of such systems should be friendly and cooperative, and if
>suitable arrangements are developed they should be supported in the
>usual ways within Debian.
> 
> CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED
> 
> 7. Failing to support non-systemd systems when such support is
>available, or offered in the form of patches (or packages),
>*should* be treated as a release critical bug.  For example: init
>scripts *must not* be deleted merely because a systemd unit is
>provided instead; patches which contribute support for other init
>systems (with no substantial effect on systemd installations)
>should be filed as bugs with severity `serious'.
> 
>This is intended to provide a lightweight but effective path to
>ensuring that reasonable support can be provided to Debian users,
>even where the maintainer's priorities lie elsewhere.  (Invoking
>the Technical Committee about individual patches is not sensible.)
> 
>If the patches are themselves RC-buggy (in the opinion of,
>initially, the maintainer, and ultimately the Release Team) then of
>course the bug report should be downgraded or closed.
> 
> 8. Maintainers of systemd components, or other gatekeepers (including
>other maintainers and the release team) sometimes have to evaluate
>technical contributions intended to support non-systemd users.  The
>acceptability to users of non-default init systems, of quality
>risks of such contributions, is a matter for the maintainers of
>non-default init systems and the surrounding community.  But such
>contributions should not impose nontrivial risks on users of the
>default configuration (systemd with Recommends installed).
> 
> NON-INIT-RELATED DECLARATIVE SYSTEMD FACILITIES
> 
> 9. systemd provides a variety of facilities 

Re: [draft] Draft text on Init Systems GR

[Thomas Goirand]

On 11/17/19 9:00 PM, Russ Allbery wrote:
> Joshua Hudson  writes:
> 
>> The debate on systemd often turns into systemd vs. sysvinit because
>> sysvinit is the working alternative right now. Unfortunately, this is a
>> poor way to frame the debate. The reality is sytemd unit files are a
>> really good idea, but systemd's hardware detection leaves much to be
>> desired.
> 
>> You're going to get stuck with a lot of debates and really stupid
>> support issues if you try to force systemd, because the hardware
>> detection frequently outsmarts itself.
> 
> systemd has been the default init system in Debian for two releases now.
> I think that water went under the bridge a long time ago, and we're
> already getting whatever support issues we were going to get.
> 
> Support issues are primarily driven by the default init system, and we're
> not reconsidering that in this discussion.
> 
> Also, there currently is no alternative init system that supports systemd
> units that I know of.  The supported init systems in Debian right now are
> systemd, sysvinit, runit, and OpenRC.  I think we should focus on making
> sure any decisions make sense for them, or deciding that we're not willing
> to continue to support them.  That means focusing on init script support.

Or getting rid of sysv-rc in the favor of OpenRC.

Thomas

Re: [draft] Draft text on Init Systems GR

[Ian Jackson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
> Ian Jackson  writes:
> > Please do formally propose it and I will give my formal blessing to it.
> 
> If I understand the process correctly, that looks like this:
> 
> I propose that point 7 of Iam's seconded proposal be replaced with point 7
> as shown here:

I accept this amendment.  The amended version should replace my
proposal.  For completeness, I enclose it.  (My ref e8942d8c.)

Thanks,
Ian.

- -8<-

Title: Support non-systemd systems, without blocking progress

PRINCIPLES

1. We wish to continue to support multiple init systems for the
   foreseeable future.  And we want to improve our systemd support.
   We are disappointed that this has had to involve another GR.

2. It is primarily for the communities in each software ecosystem to
   maintain and develop their respective software - but with the
   active support of other maintainers and gatekeepers where needed.

SYSTEMD DEPENDENCIES

3. Ideally, packages should should be fully functional with all init
   systems.  This means (for example) that daemons should ship
   traditional init scripts, or use other mechanisms to ensure that
   they are started without systemd.  It also means that desktop
   software should be installable, and ideally fully functional,
   without systemd.

4. So failing to support non-systemd systems, where no such support is
   available, is a bug.  But it is *not* a release-critical bug.
   Whether the requirement for systemd is recorded as a formal bug in
   the Debian bug system, when no patches are available, is up to the
   maintainer.

5. When a package has reduced functionality without systemd, this
   should not generally be documented as a (direct or indirect)
   Depends or Recommends on systemd-sysv.  This is because with such
   dependencies, installing such a package can attempt to switch the
   init system, which is not the what the user wanted.  For example, a
   daemon with only a systemd unit file script should still be
   installable on a non-systemd system, since it could be started
   manually.

   One consequence of this is that on non-systemd systems it may be
   possible to install software which will not work, or not work
   properly, because of an undeclared dependency on systemd.  This is
   unfortunate but trying to switch the user's init system is worse.
   We hope that better technical approaches can be developed to
   address this.

6. We recognise that some maintainers find init scripts a burden and
   we hope that the community is able to find ways to make it easier
   to add support for non-default init systems.  Discussions about the
   design of such systems should be friendly and cooperative, and if
   suitable arrangements are developed they should be supported in the
   usual ways within Debian.

CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED

7. Failing to support non-systemd systems when such support is
   available, or offered in the form of patches (or packages),
   *should* be treated as a release critical bug.  For example: init
   scripts *must not* be deleted merely because a systemd unit is
   provided instead; patches which contribute support for other init
   systems (with no substantial effect on systemd installations)
   should be filed as bugs with severity `serious'.

   This is intended to provide a lightweight but effective path to
   ensuring that reasonable support can be provided to Debian users,
   even where the maintainer's priorities lie elsewhere.  (Invoking
   the Technical Committee about individual patches is not sensible.)

   If the patches are themselves RC-buggy (in the opinion of,
   initially, the maintainer, and ultimately the Release Team) then of
   course the bug report should be downgraded or closed.

8. Maintainers of systemd components, or other gatekeepers (including
   other maintainers and the release team) sometimes have to evaluate
   technical contributions intended to support non-systemd users.  The
   acceptability to users of non-default init systems, of quality
   risks of such contributions, is a matter for the maintainers of
   non-default init systems and the surrounding community.  But such
   contributions should not impose nontrivial risks on users of the
   default configuration (systemd with Recommends installed).

NON-INIT-RELATED DECLARATIVE SYSTEMD FACILITIES

9. systemd provides a variety of facilities besides daemon startup.
   For example, creating system users or temporary directories.
   Current Debian approaches are often based on debhelper scripts.

   In general more declarative approaches are better.  Where
 - systemd provides such facility
 - a specification of the facility (or suitable subset) exists
 - the facility is better than the other approaches available
   in Debian, for example by being more declarative
 - it is reasonabl

Re: [draft] Draft text on Init Systems GR

[Kurt Roeckx]

On Mon, Nov 18, 2019 at 05:37:46PM -0700, Sean Whitton wrote:
> Hello,
> 
> On Mon 18 Nov 2019 at 04:57PM +00, Ian Jackson wrote:
> 
> > Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
> >> Ian Jackson  writes:
> >> >  + (with no substantial effect on systemd installations)
> >>
> >> Yes, that looks great to me.
> >
> > I have folded it in and the result is below.
> >
> >> Let me know if it would be helpful for me to propose it.  Happy to do so.
> >> I was also unclear on who can accept amendments to unaccepted amendments.
> >
> > Please do formally propose it and I will give my formal blessing to
> > it.
> 
> If needed: my seconding of Ian's proposal continues to apply to the
> following revised quoted amendment:

It's not needed. As long as none of the sponsors disagrees, it's accepted.


Kurt

Re: [draft] Draft text on Init Systems GR

[Kyle Robbertze]

Hi,

On 2019/11/19 02:37, Sean Whitton wrote:
> Hello,
> 
> On Mon 18 Nov 2019 at 04:57PM +00, Ian Jackson wrote:
> 
>> Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
>>> Ian Jackson  writes:
>>>>  + (with no substantial effect on systemd installations)
>>>
>>> Yes, that looks great to me.
>>
>> I have folded it in and the result is below.
>>
>>> Let me know if it would be helpful for me to propose it.  Happy to do so.
>>> I was also unclear on who can accept amendments to unaccepted amendments.
>>
>> Please do formally propose it and I will give my formal blessing to
>> it.
> 
> If needed: my seconding of Ian's proposal continues to apply to the
> following revised quoted amendment:
> 

I too, continue to second Ian's proposal with the following quoted
amendment:

>> -8<-
>>
>> Title: Support non-systemd systems, without blocking progress
>>
>> PRINCIPLES
>>
>> 1. We wish to continue to support multiple init systems for the
>>foreseeable future.  And we want to improve our systemd support.
>>We are disappointed that this has had to involve another GR.
>>
>> 2. It is primarily for the communities in each software ecosystem to
>>maintain and develop their respective software - but with the
>>active support of other maintainers and gatekeepers where needed.
>>
>> SYSTEMD DEPENDENCIES
>>
>> 3. Ideally, packages should should be fully functional with all init
>>systems.  This means (for example) that daemons should ship
>>traditional init scripts, or use other mechanisms to ensure that
>>they are started without systemd.  It also means that desktop
>>software should be installable, and ideally fully functional,
>>without systemd.
>>
>> 4. So failing to support non-systemd systems, where no such support is
>>available, is a bug.  But it is *not* a release-critical bug.
>>Whether the requirement for systemd is recorded as a formal bug in
>>the Debian bug system, when no patches are available, is up to the
>>maintainer.
>>
>> 5. When a package has reduced functionality without systemd, this
>>should not generally be documented as a (direct or indirect)
>>Depends or Recommends on systemd-sysv.  This is because with such
>>dependencies, installing such a package can attempt to switch the
>>init system, which is not the what the user wanted.  For example, a
>>daemon with only a systemd unit file script should still be
>>installable on a non-systemd system, since it could be started
>>manually.
>>
>>One consequence of this is that on non-systemd systems it may be
>>possible to install software which will not work, or not work
>>properly, because of an undeclared dependency on systemd.  This is
>>unfortunate but trying to switch the user's init system is worse.
>>We hope that better technical approaches can be developed to
>>address this.
>>
>> 6. We recognise that some maintainers find init scripts a burden and
>>we hope that the community is able to find ways to make it easier
>>to add support for non-default init systems.  Discussions about the
>>design of such systems should be friendly and cooperative, and if
>>suitable arrangements are developed they should be supported in the
>>usual ways within Debian.
>>
>> CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED
>>
>> 7. Failing to support non-systemd systems when such support is
>>available, or offered in the form of patches (or packages),
>>*should* be treated as a release critical bug.  For example: init
>>scripts *must not* be deleted merely because a systemd unit is
>>provided instead; patches which contribute support for other init
>>systems (with no substantial effect on systemd installations)
>>should be filed as bugs with severity `serious'.
>>
>>This is intended to provide a lightweight but effective path to
>>ensuring that reasonable support can be provided to Debian users,
>>even where the maintainer's priorities lie elsewhere.  (Invoking
>>the Technical Committee about individual patches is not sensible.)
>>
>>If the patches are themselves RC-buggy (in the opinion of,
>>initially, the maintainer, and ultimately the Release Team) then of
>>course the bug report should be downgraded or closed.
>>
>> 8. Maintainers of systemd components, or other gatekeepers (including
>>other maintainers

Re: [draft] Draft text on Init Systems GR

[Russ Allbery]

Ian Jackson  writes:

> Please do formally propose it and I will give my formal blessing to it.

If I understand the process correctly, that looks like this:

I propose that point 7 of Iam's seconded proposal be replaced with point 7
as shown here:

> 7. Failing to support non-systemd systems when such support is
>available, or offered in the form of patches (or packages),
>*should* be treated as a release critical bug.  For example: init
>scripts *must not* be deleted merely because a systemd unit is
>provided instead; patches which contribute support for other init
>systems (with no substantial effect on systemd installations)
>should be filed as bugs with severity `serious'.

>This is intended to provide a lightweight but effective path to
>ensuring that reasonable support can be provided to Debian users,
>even where the maintainer's priorities lie elsewhere.  (Invoking
>the Technical Committee about individual patches is not sensible.)

>If the patches are themselves RC-buggy (in the opinion of,
>initially, the maintainer, and ultimately the Release Team) then of
>course the bug report should be downgraded or closed.

(specifically to add "(with no substantial effect on systemd
installations)").

-- 
Russ Allbery (r...@debian.org)  


signature.asc
Description: PGP signature

Re: [draft] Draft text on Init Systems GR

[Sean Whitton]

Hello,

On Mon 18 Nov 2019 at 04:57PM +00, Ian Jackson wrote:

> Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
>> Ian Jackson  writes:
>> >  + (with no substantial effect on systemd installations)
>>
>> Yes, that looks great to me.
>
> I have folded it in and the result is below.
>
>> Let me know if it would be helpful for me to propose it.  Happy to do so.
>> I was also unclear on who can accept amendments to unaccepted amendments.
>
> Please do formally propose it and I will give my formal blessing to
> it.

If needed: my seconding of Ian's proposal continues to apply to the
following revised quoted amendment:

> -8<-
>
> Title: Support non-systemd systems, without blocking progress
>
> PRINCIPLES
>
> 1. We wish to continue to support multiple init systems for the
>foreseeable future.  And we want to improve our systemd support.
>We are disappointed that this has had to involve another GR.
>
> 2. It is primarily for the communities in each software ecosystem to
>maintain and develop their respective software - but with the
>active support of other maintainers and gatekeepers where needed.
>
> SYSTEMD DEPENDENCIES
>
> 3. Ideally, packages should should be fully functional with all init
>systems.  This means (for example) that daemons should ship
>traditional init scripts, or use other mechanisms to ensure that
>they are started without systemd.  It also means that desktop
>software should be installable, and ideally fully functional,
>without systemd.
>
> 4. So failing to support non-systemd systems, where no such support is
>available, is a bug.  But it is *not* a release-critical bug.
>Whether the requirement for systemd is recorded as a formal bug in
>the Debian bug system, when no patches are available, is up to the
>maintainer.
>
> 5. When a package has reduced functionality without systemd, this
>should not generally be documented as a (direct or indirect)
>Depends or Recommends on systemd-sysv.  This is because with such
>dependencies, installing such a package can attempt to switch the
>init system, which is not the what the user wanted.  For example, a
>daemon with only a systemd unit file script should still be
>installable on a non-systemd system, since it could be started
>manually.
>
>One consequence of this is that on non-systemd systems it may be
>possible to install software which will not work, or not work
>properly, because of an undeclared dependency on systemd.  This is
>unfortunate but trying to switch the user's init system is worse.
>We hope that better technical approaches can be developed to
>address this.
>
> 6. We recognise that some maintainers find init scripts a burden and
>we hope that the community is able to find ways to make it easier
>to add support for non-default init systems.  Discussions about the
>design of such systems should be friendly and cooperative, and if
>suitable arrangements are developed they should be supported in the
>usual ways within Debian.
>
> CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED
>
> 7. Failing to support non-systemd systems when such support is
>available, or offered in the form of patches (or packages),
>*should* be treated as a release critical bug.  For example: init
>scripts *must not* be deleted merely because a systemd unit is
>provided instead; patches which contribute support for other init
>systems (with no substantial effect on systemd installations)
>should be filed as bugs with severity `serious'.
>
>This is intended to provide a lightweight but effective path to
>ensuring that reasonable support can be provided to Debian users,
>even where the maintainer's priorities lie elsewhere.  (Invoking
>the Technical Committee about individual patches is not sensible.)
>
>If the patches are themselves RC-buggy (in the opinion of,
>initially, the maintainer, and ultimately the Release Team) then of
>course the bug report should be downgraded or closed.
>
> 8. Maintainers of systemd components, or other gatekeepers (including
>other maintainers and the release team) sometimes have to evaluate
>technical contributions intended to support non-systemd users.  The
>acceptability to users of non-default init systems, of quality
>risks of such contributions, is a matter for the maintainers of
>non-default init systems and the surrounding community.  But such
>contributions should not impose nontrivial risks on users of the
>default configuration (systemd with Recommends installed).
>
> NON

Re: [draft] Draft text on Init Systems GR

[Kurt Roeckx]

On Mon, Nov 18, 2019 at 12:57:04PM +, Ian Jackson wrote:
> It is not clear to me who can "accept" it - would that me be as the
> proposer of this version, or Sam as the original proposer ?  Perhaps
> Kurt's life would be made easier if Sam would, at the appropriate
> point, indicate his approval.  CC'ing secretary@ about this.  (Sorry,
> Kurt.  I think this is my bug in the constitution.)

I agree that the text is not very clear. But I think the intention
is that the proposor of one of the options can accept changes to
that option.

What is not clear is that you can accept between calling for
seconds and reaching the required seconds. But as long as none of
the sponsors object to you accepting it, I think it makes to allow
it.


Kurt

Re: [draft] Draft text on Init Systems GR

[Ian Jackson]

Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
> Ian Jackson  writes:
> >  + (with no substantial effect on systemd installations)
>
> Yes, that looks great to me.

I have folded it in and the result is below.

> Let me know if it would be helpful for me to propose it.  Happy to do so.
> I was also unclear on who can accept amendments to unaccepted amendments.

Please do formally propose it and I will give my formal blessing to
it.

Ian.

-8<-

Title: Support non-systemd systems, without blocking progress

PRINCIPLES

1. We wish to continue to support multiple init systems for the
   foreseeable future.  And we want to improve our systemd support.
   We are disappointed that this has had to involve another GR.

2. It is primarily for the communities in each software ecosystem to
   maintain and develop their respective software - but with the
   active support of other maintainers and gatekeepers where needed.

SYSTEMD DEPENDENCIES

3. Ideally, packages should should be fully functional with all init
   systems.  This means (for example) that daemons should ship
   traditional init scripts, or use other mechanisms to ensure that
   they are started without systemd.  It also means that desktop
   software should be installable, and ideally fully functional,
   without systemd.

4. So failing to support non-systemd systems, where no such support is
   available, is a bug.  But it is *not* a release-critical bug.
   Whether the requirement for systemd is recorded as a formal bug in
   the Debian bug system, when no patches are available, is up to the
   maintainer.

5. When a package has reduced functionality without systemd, this
   should not generally be documented as a (direct or indirect)
   Depends or Recommends on systemd-sysv.  This is because with such
   dependencies, installing such a package can attempt to switch the
   init system, which is not the what the user wanted.  For example, a
   daemon with only a systemd unit file script should still be
   installable on a non-systemd system, since it could be started
   manually.

   One consequence of this is that on non-systemd systems it may be
   possible to install software which will not work, or not work
   properly, because of an undeclared dependency on systemd.  This is
   unfortunate but trying to switch the user's init system is worse.
   We hope that better technical approaches can be developed to
   address this.

6. We recognise that some maintainers find init scripts a burden and
   we hope that the community is able to find ways to make it easier
   to add support for non-default init systems.  Discussions about the
   design of such systems should be friendly and cooperative, and if
   suitable arrangements are developed they should be supported in the
   usual ways within Debian.

CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED

7. Failing to support non-systemd systems when such support is
   available, or offered in the form of patches (or packages),
   *should* be treated as a release critical bug.  For example: init
   scripts *must not* be deleted merely because a systemd unit is
   provided instead; patches which contribute support for other init
   systems (with no substantial effect on systemd installations)
   should be filed as bugs with severity `serious'.

   This is intended to provide a lightweight but effective path to
   ensuring that reasonable support can be provided to Debian users,
   even where the maintainer's priorities lie elsewhere.  (Invoking
   the Technical Committee about individual patches is not sensible.)

   If the patches are themselves RC-buggy (in the opinion of,
   initially, the maintainer, and ultimately the Release Team) then of
   course the bug report should be downgraded or closed.

8. Maintainers of systemd components, or other gatekeepers (including
   other maintainers and the release team) sometimes have to evaluate
   technical contributions intended to support non-systemd users.  The
   acceptability to users of non-default init systems, of quality
   risks of such contributions, is a matter for the maintainers of
   non-default init systems and the surrounding community.  But such
   contributions should not impose nontrivial risks on users of the
   default configuration (systemd with Recommends installed).

NON-INIT-RELATED DECLARATIVE SYSTEMD FACILITIES

9. systemd provides a variety of facilities besides daemon startup.
   For example, creating system users or temporary directories.
   Current Debian approaches are often based on debhelper scripts.

   In general more declarative approaches are better.  Where
 - systemd provides such facility
 - a specification of the facility (or suitable subset) exists
 - the facility is better than the other approaches available
   in Debian, for example by being more declarative
 - it is reasonable to expect developers of non-systemd
   systems includ

Re: [draft] Draft text on Init Systems GR

[Russ Allbery]

Ian Jackson  writes:

> You have got my intent right.  How about this as a suggested fix

>patches which contribute support for other init
>systems
>  + (with no substantial effect on systemd installations)
>should be filed as bugs with severity `serious'

> leaving changes which *do* have such a substantial effect to be dealt
> with under 8.

> I say "on systemd *installations*" (emph. added) because obviously
> building two versions would have a substantial effect on build
> infrastructure etc.

> Do you think this is clearer and has the right effect ?

Yes, that looks great to me.

> I am open to other suggestions.  If we come to a conclusion on an
> improved wording here, I guess someone ought to formally propose it.  I
> guess it will fall to me to do that.

Let me know if it would be helpful for me to propose it.  Happy to do so.
I was also unclear on who can accept amendments to unaccepted amendments.

-- 
Russ Allbery (r...@debian.org)  

Re: [draft] Draft text on Init Systems GR

[Andrey Rahmatullin]

On Sun, Nov 17, 2019 at 11:24:44AM -0800, Joshua Hudson wrote:
> The debate on systemd often turns into systemd vs. sysvinit because sysvinit 
> is
> the working alternative right now. Unfortunately, this is a poor way
> to frame the
> debate. The reality is sytemd unit files are a really good idea, but systemd's
> hardware detection leaves much to be desired.
> 
> You're going to get stuck with a lot of debates and really stupid support 
> issues
> if you try to force systemd, because the hardware detection frequently 
> outsmarts
> itself.
> 
> Thus I filed an issue with systemd to separate out the early boot from the 
> rest
> of systemd so that component can be replaced independently on deployed
> systems. No, I don't think they're actually willing to do it, but it
> would squash
> most/all of the real issues.
> 
> https://github.com/systemd/systemd/issues/14058
For the record, this was closed with "afaics everything you are asking for
is already implemented, and pretty much documented".

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: [draft] Draft text on Init Systems GR

[Ian Jackson]

Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
> Ah, I think this is making me realize there's a somewhat odd conflict
> between point 7 and point 8 that I didn't notice.  The criteria in point 7
> is stronger (the contributed support does not introduce an RC bug) than in
> point 8 (the contributed change does not impose non-trivial risks on users
> of the default configuration), and now I'm unsure which would apply here.

Point 8 is primarily about systemd components.  Point 7 is about
packages in general directly supporting non-systemd setups, where the
contribution is to add that support.

> I think the best approach would be that the point 7 criteria (the patch
> needs to be applied unless it introduces an RC bug) should apply if the
> sysvinit support doesn't change behavior substantially under systemd, and
> the point 8 criteria should apply if it does.  So, for instance, changing
> the packaging to build two versions of the GNOME stack, one requiring
> systemd and one not, would use the point 7 criteria, but changing the
> build options for everyone to use the mechanism compatible with
> non-systemd systems would use the point 8 criteria.  But it's not clear to
> me that Ian's text says this.

You have got my intent right.  How about this as a suggested fix

   patches which contribute support for other init
   systems
 + (with no substantial effect on systemd installations)
   should be filed as bugs with severity `serious'

leaving changes which *do* have such a substantial effect to be dealt
with under 8.

I say "on systemd *installations*" (emph. added) because obviously
building two versions would have a substantial effect on build
infrastructure etc.

Do you think this is clearer and has the right effect ?  I am open to
other suggestions.  If we come to a conclusion on an improved wording
here, I guess someone ought to formally propose it.  I guess it will
fall to me to do that.

It is not clear to me who can "accept" it - would that me be as the
proposer of this version, or Sam as the original proposer ?  Perhaps
Kurt's life would be made easier if Sam would, at the appropriate
point, indicate his approval.  CC'ing secretary@ about this.  (Sorry,
Kurt.  I think this is my bug in the constitution.)

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: [draft] Draft text on Init Systems GR

[Thomas Goirand]

On 11/15/19 6:49 PM, Russ Allbery wrote:
> Ian Jackson  writes:
> 
>> Here is my proposal.  It is unfortunately quite long.  The reason is
>> that I am trying to address the dysfuncdtional patterns I have seen over
>> the past few years, and give specific remedies.
> 
> After sleeping on this, I am going to second this proposal.  I think it's
> superior to options one and two on Sam's ballot because it provides a
> clear path forward for the project to adopt declarative package
> configuration and it provides some much-needed clarity about
> responsibilities.
> 
> It sounds like Ian is planning on making a few changes, so I'll hold off
> on formally seconding it until there's a new draft.
> 

+1

I find Ian's draft (after all the in-progress rework) very good, and
would probably second the final proposal.

Thomas Goirand (zigo)

Re: [draft] Draft text on Init Systems GR

[Russ Allbery]

Joshua Hudson  writes:

> The debate on systemd often turns into systemd vs. sysvinit because
> sysvinit is the working alternative right now. Unfortunately, this is a
> poor way to frame the debate. The reality is sytemd unit files are a
> really good idea, but systemd's hardware detection leaves much to be
> desired.

> You're going to get stuck with a lot of debates and really stupid
> support issues if you try to force systemd, because the hardware
> detection frequently outsmarts itself.

systemd has been the default init system in Debian for two releases now.
I think that water went under the bridge a long time ago, and we're
already getting whatever support issues we were going to get.

Support issues are primarily driven by the default init system, and we're
not reconsidering that in this discussion.

Also, there currently is no alternative init system that supports systemd
units that I know of.  The supported init systems in Debian right now are
systemd, sysvinit, runit, and OpenRC.  I think we should focus on making
sure any decisions make sense for them, or deciding that we're not willing
to continue to support them.  That means focusing on init script support.

-- 
Russ Allbery (r...@debian.org)  

Re: [draft] Draft text on Init Systems GR

[Joshua Hudson]

The debate on systemd often turns into systemd vs. sysvinit because sysvinit is
the working alternative right now. Unfortunately, this is a poor way
to frame the
debate. The reality is sytemd unit files are a really good idea, but systemd's
hardware detection leaves much to be desired.

You're going to get stuck with a lot of debates and really stupid support issues
if you try to force systemd, because the hardware detection frequently outsmarts
itself.

Thus I filed an issue with systemd to separate out the early boot from the rest
of systemd so that component can be replaced independently on deployed
systems. No, I don't think they're actually willing to do it, but it
would squash
most/all of the real issues.

https://github.com/systemd/systemd/issues/14058

Re: [draft] Draft text on Init Systems GR

[Russ Allbery]

Russ Allbery  writes:
> Ansgar  writes:

>> So three hypothetical examples:

>>  - a hypothetical GNOME version that requires a build-time choice
>>between `systemd --user` and the traditional session implementation;
>>(GNOME can use `systemd --user` already[1], but it's not a build-time
>>choice.)  I guess elogind could in theory start a `systemd --user`
>>instance even when pid-1 is not systemd, but it's probably not
>>realistic to expect that to be implemented.

> The criteria here under Ian's proposal is stated in point 8, "But such
> contributions should not impose nontrivial risks on users of the default
> configuration (systemd with Recommends installed)."  So it would be a
> determination of the GNOME maintainers, appealable to the Technical
> Committee, whether using the traditional session implementation would
> impose a nontrivial risk to the users of the default configuration.

> If the traditional session implementation has RC bugs, point 7 would also
> apply and would be a strong argument in favor of switching to systemd
> --user.

Ah, I think this is making me realize there's a somewhat odd conflict
between point 7 and point 8 that I didn't notice.  The criteria in point 7
is stronger (the contributed support does not introduce an RC bug) than in
point 8 (the contributed change does not impose non-trivial risks on users
of the default configuration), and now I'm unsure which would apply here.

I think the best approach would be that the point 7 criteria (the patch
needs to be applied unless it introduces an RC bug) should apply if the
sysvinit support doesn't change behavior substantially under systemd, and
the point 8 criteria should apply if it does.  So, for instance, changing
the packaging to build two versions of the GNOME stack, one requiring
systemd and one not, would use the point 7 criteria, but changing the
build options for everyone to use the mechanism compatible with
non-systemd systems would use the point 8 criteria.  But it's not clear to
me that Ian's text says this.

-- 
Russ Allbery (r...@debian.org)  

Re: [draft] Draft text on Init Systems GR

[Russ Allbery]

Ian, if you have a moment, could you also weigh in here to confirm that
I've understood the intent of your proposal correctly?

Ansgar  writes:

> So three hypothetical examples:

>  - a hypothetical GNOME version that requires a build-time choice
>between `systemd --user` and the traditional session implementation;
>(GNOME can use `systemd --user` already[1], but it's not a build-time
>choice.)  I guess elogind could in theory start a `systemd --user`
>instance even when pid-1 is not systemd, but it's probably not
>realistic to expect that to be implemented.

The criteria here under Ian's proposal is stated in point 8, "But such
contributions should not impose nontrivial risks on users of the default
configuration (systemd with Recommends installed)."  So it would be a
determination of the GNOME maintainers, appealable to the Technical
Committee, whether using the traditional session implementation would
impose a nontrivial risk to the users of the default configuration.

If the traditional session implementation has RC bugs, point 7 would also
apply and would be a strong argument in favor of switching to systemd
--user.

>  - a hypothetical network management program that requires a build-time
>choice between using systemd-networkd or isc-dhcp-{server,client} to
>manage network connections.  (Had NM used networkd would likely have
>saved me some fiddling with settings recently and some things would
>just have worked out-of-the-box.)

> In case of build-time choices someone could submit a patch to switch the
> program to use another option even when this provides a less good
> experience for people using systemd (though still usable).

I think this is the same.

(In this case, I'll also add the editorial comment that I think making
this sort of choice a build-time switch is poor engineering.)

>  - a hypothetical GNOME version requires (and does not really work
>without) a new or updated logind interface that elogind doesn't
>provide yet, but that could be implemented.  Say for some device
>access or so.

> Would updating the software be blocked?

I don't see how it would be under Ian's proposal.  It's a regression in
sysvinit support, but I don't see anything in Ian's proposal that calls
out upstream removal of sysvinit support as distinct from any other
upstream that only supports systemd.  This introduces a bug under point 4,
but that bug is not RC.

I suppose you could argue that a patch reverting the upstream version of
the software could be considered "available support" under point 7, but I
don't think this holds up to scrutiny.  Among other things, pinning to an
old version of upstream is pretty obviously an RC bug as soon as upstream
stops supporting that version, due to security support considerations.

It *is* the case under Ian's proposal that if someone forward-ports the
elogind support from an older version of GNOME and provides that as a
patch that can be applied without a non-trivial risk to systemd users, the
maintainer is in effect obligated to apply that patch.  Obviously this is
not a great situation to be in and would mean a ton of ongoing work by the
sysvinit patch maintainer, so I don't think it's likely we would end up in
that sort of situation for all that long.  There would be a strong
motivation for sysvinit users to find some other approach, such as an
improved elogind.

(In reality, my personal guess is that we'll drop sysvinit support for
GNOME.  I'm not sure the cross-section of GNOME users and sysvinit users
is large enough to maintain that combination.  My subjective impression is
that most of the people who want to stick with sysvinit are also not big
fans of GNOME's design decisions and are more likely to use some other
desktop environment or window manager.  But I don't want to assume that my
guess is correct, or get in the way of anyone who does want to find a way
to make this work.)

-- 
Russ Allbery (r...@debian.org)  

Re: [draft] Draft text on Init Systems GR

[Ansgar]

Russ Allbery writes:
> Ansgar  writes:
>> Note that this would also block updating upstream packages to new
>> releases, possibly delaying development for a long time.  I don't think
>> we need much slower development cycles.
>
> I'm not sure why you think this is the case.  Could you explain more about
> what upstream package blocking you expect?  Upstreams that only support
> systemd don't need to wait for a Policy specification of the facilities
> they rely on under Ian's proposal;

https://lists.debian.org/debian-vote/2019/11/msg00106.html was still
mentioning new logind features so I'm not sure that's out of scope.

So three hypothetical examples:

 - a hypothetical GNOME version that requires a build-time choice
   between `systemd --user` and the traditional session implementation;
   (GNOME can use `systemd --user` already[1], but it's not a build-time
   choice.)  I guess elogind could in theory start a `systemd --user`
   instance even when pid-1 is not systemd, but it's probably not
   realistic to expect that to be implemented.

   As far as I remember consolekit vs systemd-logind was a build-time
   choice in the past for some programs.

[1]: 
https://blogs.gnome.org/benzea/2019/10/01/gnome-3-34-is-now-managed-using-systemd/

 - a hypothetical network management program that requires a build-time
   choice between using systemd-networkd or isc-dhcp-{server,client} to
   manage network connections.  (Had NM used networkd would likely have
   saved me some fiddling with settings recently and some things would
   just have worked out-of-the-box.)

In case of build-time choices someone could submit a patch to switch the
program to use another option even when this provides a less good
experience for people using systemd (though still usable).

What would happen then?  Would the maintainer have to apply the patch?

 - a hypothetical GNOME version requires (and does not really work
   without) a new or updated logind interface that elogind doesn't
   provide yet, but that could be implemented.  Say for some device
   access or so.

Would updating the software be blocked?

> the Policy discussion is only about
> general adoption of the facility to replace existing Debian-specific
> approaches.  Ian's proposal only requires that the maintainers accept
> patches to port systemd-only software to other init systems once those
> patches have been written, and asks that Policy not require systemd-only
> services be used by packages that aren't otherwise systemd-only without
> this specification and transition period.

I've less concerns about delaying replacing Debian-specific bits, say by
adopting tmpfiles.  That's slow anyway ;-)

(Though I would like to see Policy recommending packages to ship
tmpfiles stuff to create directories under /var and/or /etc in a safe
way; and to recreate them if an administrator deleted for example
directories under /var/cache.)

Ansgar

Re: [draft] Draft text on Init Systems GR

[Russ Allbery]

Ansgar  writes:

> It doesn't have to have the same complexity as logind or udev.  Keep in
> mind that Policy doesn't even document init scripts properly: in
> particular LSB comment headers and such are also missing.  We weren't
> able to document that in Policy for a long time and other Policy
> requirements are very unclear as a consequence.  (Or multiarch for
> another example.)

Yes, I agree that the lack of resources on the Policy side is a downside
to any of the options that rely on the Policy process.  It's a downside
risk that I'm willing to take, and I think there are motivated people who
want to adopt those interfaces and therefore would be willing to write
Policy text to do so and that this sort of GR would unblock that work, but
I could be wrong.

> Note that this would also block updating upstream packages to new
> releases, possibly delaying development for a long time.  I don't think
> we need much slower development cycles.

I'm not sure why you think this is the case.  Could you explain more about
what upstream package blocking you expect?  Upstreams that only support
systemd don't need to wait for a Policy specification of the facilities
they rely on under Ian's proposal; the Policy discussion is only about
general adoption of the facility to replace existing Debian-specific
approaches.  Ian's proposal only requires that the maintainers accept
patches to port systemd-only software to other init systems once those
patches have been written, and asks that Policy not require systemd-only
services be used by packages that aren't otherwise systemd-only without
this specification and transition period.

> So submit a copy of all systemd man pages to Policy and update them
> every few months? (To document unit files without external references.)

I wouldn't expect us to pick unit files as one of the interfaces to
document in the near future.  We would start with the simpler features,
such as specific features within unit files (like DynamicUser).

Most unit file features are not mandatory for the program to run and hence
probably wouldn't need to be documented separately in Policy because they
don't constitute a required interface.  We would need to document things
like the socket activation protocol or tmpfiles.d or sysusers.d.

> I think pretty much any feature has value.  The debate should be over
> its relative merits, sadly some other people find it necessary to
> preemptively call unspecific features that some might want to use later
> (and thus clearly would see value in them) to be "of questionable
> value".

That's a very good point.

If something is popular and people want to use it, saying that it has no
value is pretty obviously wrong.  Anything that people want to use has
some sort of value.

-- 
Russ Allbery (r...@debian.org)  

Re: [draft] Draft text on Init Systems GR

[Ian Jackson]

Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
> Ian Jackson  writes:
> > Here is my proposal.  It is unfortunately quite long.  The reason is
> > that I am trying to address the dysfuncdtional patterns I have seen over
> > the past few years, and give specific remedies.
> 
> After sleeping on this, I am going to second this proposal.  I think it's
> superior to options one and two on Sam's ballot because it provides a
> clear path forward for the project to adopt declarative package
> configuration and it provides some much-needed clarity about
> responsibilities.

Thank you.

> It sounds like Ian is planning on making a few changes, so I'll hold off
> on formally seconding it until there's a new draft.

I need to deal with Sam's comments about the "risk" paragraph.
I will then make a formal proposal.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: [draft] Draft text on Init Systems GR

[Ansgar]

Russ Allbery writes:
> Ansgar writes:
>> On Thu, 2019-11-14 at 18:29 -0800, Russ Allbery wrote:
>>> As with Dmitry's proposal, I'm not seconding this because it's not my
>>> own first choice, but I would vote this above further discussion and
>>> I'm satisfied that it's clear about the Policy implications.
>
>> Do you think it is realistic/practical to require documentation for
>> interfaces such as logind to be included into Policy (without references
>> to external documents) before they are allowed to be used in Debian by
>> any packages?
>
> I was assuming that logind was out of scope (as was udev) because both
> have already been adopted by Debian, so this isn't the same situation that
> Ian's proposal is describing.  The remaining facilities that I was
> thinking about are much more straightforward to describe.
>
> You raise a good point that this may be challenging if another interface
> of the complexity of logind or udev is added and Debian wants to adopt it.
> I'm willing to take that risk, but it's a risk.

It doesn't have to have the same complexity as logind or udev.  Keep in
mind that Policy doesn't even document init scripts properly: in
particular LSB comment headers and such are also missing.  We weren't
able to document that in Policy for a long time and other Policy
requirements are very unclear as a consequence.  (Or multiarch for
another example.)

Given that history, I'm not sure we would be able to introduce any new
facilities via Policy in a reasonable amount of time and don't think it
is reasonable to totally block usage before this has happened (plus
additional 12 months).

Note that this would also block updating upstream packages to new
releases, possibly delaying development for a long time.  I don't think
we need much slower development cycles.

> I expect if that happened
> we would likely treat it similarly to the FHS and incorporate a copy of
> the relevant specification into the debian-policy package rather than
> trying to rewrite it.  (This achieves my understanding of what Ian is
> after, namely that the specification itself not be a moving target from
> systemd upstream but go through the Policy change process when it's
> updated.)

So submit a copy of all systemd man pages to Policy and update them
every few months? (To document unit files without external references.)
I honestly don't see much advantage over just referring to external
documentation and possibly list exceptions in Policy (should they
exist), i.e. follow upstream changes by default, clarify deviations if
necessary.

(Unrelated: should LSB be included in Policy?  We possibly require some
parts of that, such as the init script parts...)

>> What do you think should happen when logind gains a new feature (or "new
>> systemd subfeatures of questionable value" as some would say)?  That
>> would seem to (re)trigger the requirement to incorporate logind into
>> Policy (if agreement can be reached) and wait up to a year before
>> using it...
>
> I'm assuming that's not the case, but yes, maybe that's worth clarifying.
> I'm not particularly eager to try to maintain a specification of logind
> inside Policy.

Me neither.  I very much prefer to refer to external documentation
(Don't Repeat Yourself).

(I've also seen LSB documentation for library interfaces.  Please let's
not go anywhere in that direction.)

>> Would calling sysvinit or subfeatures like elogind to be "of
>> questionable value" still be acceptable? :)
>
> I think calling sysvinit of questionable value is clearly factually
> incorrect.  It performs a necessary task in a UNIX system, so it clearly
> has value.  The debate is over its *relative merits*, not it's value.  I'd
> therefore rather people not make statements like that because I think
> they're sloppy and seem more designed to indicate tribal affiliation or
> rile people up than to communicate information.
>
> I think calling specific features of *any* piece of software "of
> questionable value" has to be within bounds for a technical
> discussion.

I think pretty much any feature has value.  The debate should be over
its relative merits, sadly some other people find it necessary to
preemptively call unspecific features that some might want to use later
(and thus clearly would see value in them) to be "of questionable
value".

Ansgar

Re: [draft] Draft text on Init Systems GR

[Ian Jackson]

Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
> I was assuming that logind was out of scope (as was udev) because both
> have already been adopted by Debian, so this isn't the same situation that
> Ian's proposal is describing.  The remaining facilities that I was
> thinking about are much more straightforward to describe.

For logind we have elogind.  So (now that elogind is in bullseye) I
hope that this is not going to be significant point of contention in
practice.  Does this need mentioning ?  If so, what points of
contention do we expect ?  "logind grows a new feature" ought not to
be a significant difficulty since we would expect that elogind would
also grow that same feature.

I would be happy to accept wording suggestions which would help
clarify this.

> You raise a good point that this may be challenging if another interface
> of the complexity of logind or udev is added and Debian wants to adopt it.
> I'm willing to take that risk, but it's a risk.

This doesn't seem to be on the horizon as yet.  My proposal is indeed
much less specific about how to deal with such a situation.  It gives
vague general principles but doesn't nail down the ground rules for
cooperation, the way it does for the existing known problems.

I don't think we can sensibly make a decision about this hypothetical
situation, now.  Whether we would want to adopt such a thing would
depend on what it was like and what the implications were.  The best
we can hope for is that when we get to this bridge we (1) have some
more experience of peaceful coexistence (2) we can get a good-enough
consensus on something that is tolerable to most people.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: [draft] Draft text on Init Systems GR

[Russ Allbery]

Ian Jackson  writes:

> Here is my proposal.  It is unfortunately quite long.  The reason is
> that I am trying to address the dysfuncdtional patterns I have seen over
> the past few years, and give specific remedies.

After sleeping on this, I am going to second this proposal.  I think it's
superior to options one and two on Sam's ballot because it provides a
clear path forward for the project to adopt declarative package
configuration and it provides some much-needed clarity about
responsibilities.

It sounds like Ian is planning on making a few changes, so I'll hold off
on formally seconding it until there's a new draft.

-- 
Russ Allbery (r...@debian.org)  

Re: [draft] Draft text on Init Systems GR

[Russ Allbery]

Ansgar  writes:
> On Thu, 2019-11-14 at 18:29 -0800, Russ Allbery wrote:

>> As with Dmitry's proposal, I'm not seconding this because it's not my
>> own first choice, but I would vote this above further discussion and
>> I'm satisfied that it's clear about the Policy implications.

> Do you think it is realistic/practical to require documentation for
> interfaces such as logind to be included into Policy (without references
> to external documents) before they are allowed to be used in Debian by
> any packages?

I was assuming that logind was out of scope (as was udev) because both
have already been adopted by Debian, so this isn't the same situation that
Ian's proposal is describing.  The remaining facilities that I was
thinking about are much more straightforward to describe.

You raise a good point that this may be challenging if another interface
of the complexity of logind or udev is added and Debian wants to adopt it.
I'm willing to take that risk, but it's a risk.  I expect if that happened
we would likely treat it similarly to the FHS and incorporate a copy of
the relevant specification into the debian-policy package rather than
trying to rewrite it.  (This achieves my understanding of what Ian is
after, namely that the specification itself not be a moving target from
systemd upstream but go through the Policy change process when it's
updated.)

> What do you think should happen when logind gains a new feature (or "new
> systemd subfeatures of questionable value" as some would say)?  That
> would seem to (re)trigger the requirement to incorporate logind into
> Policy (if agreement can be reached) and wait up to a year before using
> it...

I'm assuming that's not the case, but yes, maybe that's worth clarifying.
I'm not particularly eager to try to maintain a specification of logind
inside Policy.

> Would calling sysvinit or subfeatures like elogind to be "of
> questionable value" still be acceptable? :)

I think calling sysvinit of questionable value is clearly factually
incorrect.  It performs a necessary task in a UNIX system, so it clearly
has value.  The debate is over its *relative merits*, not it's value.  I'd
therefore rather people not make statements like that because I think
they're sloppy and seem more designed to indicate tribal affiliation or
rile people up than to communicate information.

I think calling specific features of *any* piece of software "of
questionable value" has to be within bounds for a technical discussion.

-- 
Russ Allbery (r...@debian.org)  

Re: [draft] Draft text on Init Systems GR

[Ansgar]

Hi Russ,

On Thu, 2019-11-14 at 18:29 -0800, Russ Allbery wrote:
> As with Dmitry's proposal, I'm not seconding this because it's not my own
> first choice, but I would vote this above further discussion and I'm
> satisfied that it's clear about the Policy implications.

Do you think it is realistic/practical to require documentation for
interfaces such as logind to be included into Policy (without
references to external documents) before they are allowed to be used in
Debian by any packages?

(Can one require the same for, say, use of non-standard libc
extensions?)

What do you think should happen when logind gains a new feature (or
"new systemd subfeatures of questionable value" as some would say)? 
That would seem to (re)trigger the requirement to incorporate logind
into Policy (if agreement can be reached) and wait up to a year before
using it...

> >  * Negative general comments about software and their communities,
> >including both about systemd itself and about non-systemd init
> >systems, are strongly deprecated.
> 
> This sense of deprecated is (I think) en_UK, or at least it reads oddly to
> this en_US reader.  I'm mentally translating it as "discouraged," but I
> wonder if something like "are not acceptable within the Debian Project"
> might be closer to the meaning you're intending.

Would calling sysvinit or subfeatures like elogind to be "of
questionable value" still be acceptable? :)

Ansgar

Re: [draft] Draft text on Init Systems GR

[Ansgar]

On Fri, 2019-11-15 at 07:11 -0500, Sam Hartman wrote:
> Ian>  * Declining to accept init scripts, or arguing against the
> Ian> inclusion of init scripts, on the grounds that they should
> be
> Ian> properly tested by the maintainer and the author doesn't
> Ian> consider testing them to be a good use of time.

I guess the same applies to people refusing to include native systemd
services?  Or ignoring patches that add such.

> Ian>  Such contributions should be accepted, even
> Ian> if they are or may be of compromised quality, if the
> Ian> quality/risk is acceptable to the maintainers of non-default
> Ian> init systems and the surrounding community
> sh> and the risk will be born by the users of non-default
> sh> initsystems.  To the extent that the risk will be born by
> users
> sh> of default initsystems, normal procedures for judging
> sh> acceptable risk should be used.

There are various risks that seemingly innocent changes to support
alternatives trigger:

 - dependencies sometimes pull in alternatives, even though they
   shouldn't be installed.
   This causes unwanted behavior.  Sometimes package managers will 
   propose very unexpected solutions.
   Example: systemd-shim has popcon ~6000, noticably more than 
   sysvinit-core.  Having systemd-shim installed, or
   removed-but-not-purged, caused problems in the past when using 
   systemd's implementation for init & logind.

 - the decision to require /etc/init.d/* to be conffiles causes 
   problems with removed, but not purged files.  The only way to deal 
   with this is to remove problematic files in other packages which is
   not a good solution.

   Conffiles also are annoying when maintaining packages as they need 
   special handling which maintainers often forget (resulting in more 
   left-over, outdated files which might cause problems at unexpected  
   later times).  They are also annoying for users; Debian has two 
   different override mechanisms for /etc/init.d/* so users don't have
   to deal with the problems: /etc/default/* and the lesser known
   /etc/insserv/override/* & /usr/share/insserv/override/*.

   As we *require* init implementations to use /etc/init.d/* this 
   causes even problems when native systemd units are provided as 
   those get properly removed and thus the sysv-compat layer gets 
   activated.  (A policy question: do we require alternatives to also 
   support the /etc/insserv/override & /usr/share/insserv/override/*
   mechanisms that provide dependency information for sysvinit script?)

   There is also the stateless-system ideas that some people are 
   interested which is easier the less config files in /etc are.

   (Sadly sysvinit refused to support alternatives such as also 
   looking into /usr/lib/init.d/* in addition to /etc/init.d/* or
   such; it would be nice if they were open to make it easier to 
   support sysvinit without running into such problems.)

Ansgar

Re: [draft] Draft text on Init Systems GR

[Sam Hartman]

> "Ian" == Ian Jackson  writes:


Ian> The patterns I am trying to address with this are things like:

Ian>  * Vague RC bug reports against pieces of the non-systemd
Ian> ecosystem, which do not actually describe a particular bug, or
Ian> an approach acceptable to the submitter, and are therefore
Ian> unresolvable.
 
Ian>  * Maintainers of key packages declining to relax strong
Ian> dependencies on systemd components on the grounds of fairly
Ian> marginal differences in functionality when a non-systemd
Ian> alternative is chosen.

Ian>  * Declining to accept init scripts, or arguing against the
Ian> inclusion of init scripts, on the grounds that they should be
Ian> properly tested by the maintainer and the author doesn't
Ian> consider testing them to be a good use of time.

Ian>  * In general, blocking the work of non-systemd contributors on
Ian> the grounds that the arrangement that the non-systemd
Ian> contributors are trying to create for non-systemd users is
Ian> somehow suboptimal or broken, in the opinion of the
Ian> systemd-supporting gatekeepers (be that maintainers, members of
Ian> the release team, or anyone else).

Ian> It is really unfortunate, but I have seen multiple examples of
Ian> each of the first three specific patterns above.  IMO we must
Ian> address this.

I strongly agree.
I've also seen non-systemd contributors being
inappropriate--disrespectful, abusing the BTS, and generally not being
excellent to each other.
I understand in the past you can probably find examples of systemd
contributors doing that, and certainly I've seen the pattern of
doomssaying about the longterm viability of non-system solutions.
Today though, systemd contributors seem to block or produce vague  and
unactionable objections when they are being obstructive.
Non-systemd contributors find themselves in a position of anger and
probably fear and seem to be lashing out in frustration.

I want to stress that I'm not judging anyone--not either side.  I
understand how we get to this point.
But I strongly believe we must stop this behavior.  We should figure out
which work we're willing to do, do that work professionally, and
politely decline the rest.
It sounds like we share that goal, even if we see the approaches to get
there differently.

I think that the DPL, the TC, and anything the TC might evolve into will
be critical forces in moving forward after the GR.  For me as DPL, the
big question is which direction to go to resolve the pattern.

Ian> How about:

Yeah this is much better.

I do have a suggestion that I've included below.
 we close in on intent.
 My wording is not great, but we can refine wording after

Ian>   Maintainers of systemd components, or other gatekeepers
Ian> (including other maintainers and the release team) sometimes
Ian> have to evaluate technical contributions intended to support
Ian> non-systemd users.  Such contributions should be accepted, even
Ian> if they are or may be of compromised quality, if the
Ian> quality/risk is acceptable to the maintainers of non-default
Ian> init systems and the surrounding community
sh> and the risk will be born by the users of non-default
sh> initsystems.  To the extent that the risk will be born by users
sh> of default initsystems, normal procedures for judging
sh> acceptable risk should be used.

Ian> Ian.

Ian> -- Ian Jackson  These opinions
Ian> are my own.

Ian> If I emailed you from an address @fyvzl.net or @evade.org.uk,
Ian> that is a private address which bypasses my fierce spamfilter.

Re: [draft] Draft text on Init Systems GR

[Ian Jackson]

Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
> I wish that a GR had the moral suasion that would get everyone to be
> excellent to each other, but I'm somewhat dubious.  I'm not a huge fan of
> trying to tackle that in the same GR as the technical questions, but I
> respect why you want to do so and I would still vote this above further
> discussion.
...
> >  * Ideally, packages should not Depend on or Recommend systemd, and
> >should be fully functional with all init systems.  This means (for
> >example) that daemons should ship traditional init scripts, or use
> >other mechanisms to ensure that they are started without systemd.
> >It also means that desktop software should be installable, and
> >ideally fully functional, without systemd.
> 
> I think using Depend and Recommend here adds more confusion than clarity
> since a lot of software doesn't Depend or Recommend systemd the package.
> Instead, the dependency is on libpam-systemd or systemd-sysv or udev, and
> there are different mechanisms in place to handle (or not handle) those.

I have changed this to delete the part about Depends etc.  Now it
reads simply.

 | Ideally, packages should should be fully functional with all init
 | systems.

> >If policy consensus cannot be reached on such a facility, the
> >Technical Committee should decide based on the project's wishes as
> >expressed in this GR.
> 
> This all sounds workable to me as a Policy editor.

Thanks.

> >  * Negative general comments about software and their communities,
> >including both about systemd itself and about non-systemd init
> >systems, are strongly deprecated.
> 
> This sense of deprecated is (I think) en_UK, or at least it reads oddly to
> this en_US reader.  I'm mentally translating it as "discouraged," but I
> wonder if something like "are not acceptable within the Debian Project"
> might be closer to the meaning you're intending.

"discouraged" will do.

Thanks for the comments.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: [draft] Draft text on Init Systems GR

[Ian Jackson]

Sam Hartman writes ("Re: [draft] Draft text on Init Systems GR"):
> [Ian's proposal]
> >It is also for maintainers of
> >   non-default init systems, and the surrounding community, to decide
> >   what level of compromised functionality is acceptable to users of
> >   non-default init systems.
> 
> 
> Every time I read that, I hear that the non-default init system
> community wants to be able to block other people's work until they are
> satisfied that the level of functionality is not too compromised.

That is the opposite of what I intend.  (Or, maybe, the converse.)

> My understanding is that you are not actually trying to do that.
> So, if you are not trying to block other people, but instead are trying
> to avoid having non-default init users blocked can we find wording that
> is more clear?

Obviously this part needs to be reworded if it can be misunderstood so
radically.

The patterns I am trying to address with this are things like:

 * Vague RC bug reports against pieces of the non-systemd ecosystem,
   which do not actually describe a particular bug, or an approach
   acceptable to the submitter, and are therefore unresolvable.
 
 * Maintainers of key packages declining to relax strong dependencies
   on systemd components on the grounds of fairly marginal differences
   in functionality when a non-systemd alternative is chosen.

 * Declining to accept init scripts, or arguing against the inclusion
   of init scripts, on the grounds that they should be properly tested
   by the maintainer and the author doesn't consider testing them to
   be a good use of time.

 * In general, blocking the work of non-systemd contributors on the
   grounds that the arrangement that the non-systemd contributors are
   trying to create for non-systemd users is somehow suboptimal or
   broken, in the opinion of the systemd-supporting gatekeepers (be
   that maintainers, members of the release team, or anyone else).

It is really unfortunate, but I have seen multiple examples of each of
the first three specific patterns above.  IMO we must address this.

How about:

  Maintainers of systemd components, or other gatekeepers (including
  other maintainers and the release team) sometimes have to evaluate
  technical contributions intended to support non-systemd users.  Such
  contributions should be accepted, even if they are or may be of
  compromised quality, if the quality/risk is acceptable to the
  maintainers of non-default init systems and the surrounding
  community.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: [draft] Draft text on Init Systems GR

[Ian Jackson]

Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
> Wouter Verhelst  writes:
> > The problem with this is that it, essentially, promotes drive-by
> > patching: someone would like to use a program, but it doesn't come with
> > support for their init system.
> >
> > So they write that support, test it perfunctorily (enough for their use
> > case), and file a bug against the package. The maintainer is now
> > required to include it, because RC.

So far, this is my intent.

> > But let's assume there's a critical bug in the support they wrote.
> > Something that during the right phase of the moon could eat data.
> > That's RC, too.

But when this happens, my intent is what Russ writes:

> While I agree that Ian's wording doesn't say this explicitly, my
> assumption is that the maintainer could remove the sysvinit support if it
> is itself RC-buggy and the maintainer wasn't willing to fix it, by analogy
> to the case in the last paragraph above.  Obviously, to be consistent with
> the rest of Ian's proposed wording, this should be done only as a last
> resort and after seeking help from the sysvinit community to fix the bug
> properly.
> 
> That being said, the other point that Ian is making is that it's up to the
> sysvinit community to decide whether an RC bug that only affects the
> sysvinit community is actually RC.  So in this case the release
> criticality of the bug would be decided by the same community which is on
> the hook to fix it, which seems fair.

I would be very open to wording change suggestions to address this
issue.

> It's not clear that this is technically feasible, so I'm not sure that it
> makes sense to mandate this solution in a GR.

Right.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: [draft] Draft text on Init Systems GR

[Wouter Verhelst]

On Thu, Nov 14, 2019 at 06:32:32PM -0800, Russ Allbery wrote:
> Wouter Verhelst  writes:
> > I think a better solution is to accept that some maintainers simply
> > won't have the time or inclination to maintain support for non-default
> > init systems, and that such init scripts (or whatever) should therefore
> > be packaged separately from the main package, maintained by someone who
> > actually uses the init system in question.
> 
> It's not clear that this is technically feasible, so I'm not sure that it
> makes sense to mandate this solution in a GR.

I'm not so sure about that. What do you think makes it not technically
feasible?

We have historically shipped init scripts with the daemon that they serve, but
there is no reason why we wouldn't be able to change that behavior.
There could definitely be a package "initscripts" that contains init
scripts which call binaries not in the same package.

(in fact...)

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: [draft] Draft text on Init Systems GR

[Russ Allbery]

Wouter Verhelst  writes:
> On Thu, Nov 14, 2019 at 06:36:53PM +, Ian Jackson wrote:

>> CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED
>> 
>>  * Failing to support non-systemd systems when such support is
>>available, or offered in the form of patches (or packages),
>>*should* be treated as a release critical bug.  For example: init
>>scripts *must not* be deleted merely because a systemd unit is
>>provided instead; patches which contribute support for other init
>>systems should be filed as bugs with severity `serious'.
>> 
>>This is intended to provide a lightweight but effective path to
>>ensuring that reasonable support can be provided to Debian users,
>>even where the maintainer's priorities lie elsewhere.  (Invoking
>>the Technical Committee about individual patches is not sensible.)
>> 
>>If the patches are themselves RC-buggy (in the opinion of,
>>initially, the maintainer, and ultimately the Release Team) then of
>>course the bug report should be downgraded or closed.

> The problem with this is that it, essentially, promotes drive-by
> patching: someone would like to use a program, but it doesn't come with
> support for their init system.

> So they write that support, test it perfunctorily (enough for their use
> case), and file a bug against the package. The maintainer is now
> required to include it, because RC.

> But let's assume there's a critical bug in the support they wrote.
> Something that during the right phase of the moon could eat data.
> That's RC, too.

While I agree that Ian's wording doesn't say this explicitly, my
assumption is that the maintainer could remove the sysvinit support if it
is itself RC-buggy and the maintainer wasn't willing to fix it, by analogy
to the case in the last paragraph above.  Obviously, to be consistent with
the rest of Ian's proposed wording, this should be done only as a last
resort and after seeking help from the sysvinit community to fix the bug
properly.

That being said, the other point that Ian is making is that it's up to the
sysvinit community to decide whether an RC bug that only affects the
sysvinit community is actually RC.  So in this case the release
criticality of the bug would be decided by the same community which is on
the hook to fix it, which seems fair.

> The maintainer is now forced to choose between dropping the support
> again, resulting in (most likely) another attempt; investing a lot of
> time in fixing the bug; or leaving it unpatched (and allowing for their
> users to have their data eaten).

I'm not sure why another attempt is a poor outcome.

> I think a better solution is to accept that some maintainers simply
> won't have the time or inclination to maintain support for non-default
> init systems, and that such init scripts (or whatever) should therefore
> be packaged separately from the main package, maintained by someone who
> actually uses the init system in question.

It's not clear that this is technically feasible, so I'm not sure that it
makes sense to mandate this solution in a GR.

-- 
Russ Allbery (r...@debian.org)  

Re: [draft] Draft text on Init Systems GR

[Russ Allbery]

Ian Jackson  writes:

> Here is my proposal.  It is unfortunately quite long.  The reason is
> that I am trying to address the dysfuncdtional patterns I have seen over
> the past few years, and give specific remedies.

I wish that a GR had the moral suasion that would get everyone to be
excellent to each other, but I'm somewhat dubious.  I'm not a huge fan of
trying to tackle that in the same GR as the technical questions, but I
respect why you want to do so and I would still vote this above further
discussion.

As with Dmitry's proposal, I'm not seconding this because it's not my own
first choice, but I would vote this above further discussion and I'm
satisfied that it's clear about the Policy implications.

>  * Ideally, packages should not Depend on or Recommend systemd, and
>should be fully functional with all init systems.  This means (for
>example) that daemons should ship traditional init scripts, or use
>other mechanisms to ensure that they are started without systemd.
>It also means that desktop software should be installable, and
>ideally fully functional, without systemd.

I think using Depend and Recommend here adds more confusion than clarity
since a lot of software doesn't Depend or Recommend systemd the package.
Instead, the dependency is on libpam-systemd or systemd-sysv or udev, and
there are different mechanisms in place to handle (or not handle) those.

Thankfully, I think the first clause here is redundant with the rest of
the paragraph anyway, and you can just say "Ideally, packages should be
fully functional with all init systems" and continue as you did.

>  * systemd provides a variety of facilities besides daemon startup.
>For example, creating system users or temporary directories.
>Current Debian approaches are often based on debhelper scripts.

>In general more declarative approaches are better.  Where
>  - systemd provides such facility
>  - a specification of the facility (or suitable subset) exists
>  - the facility is better than the other approaches available
>in Debian, for example by being more declarative
>  - it is reasonable to expect developers of non-systemd
>systems including non-Linux systems to implement it
>  - including consideration of the amount of work involved
>the facility should be documented in Debian Policy (by textual
>incorporation, not by reference to an external document).  The
>transition should be smooth for all users.  The non-systemd
>community should be given at least 6 months, preferably at least 12
>months, to develop their implementation.  (The same goes for any
>future enhancements.)

>If policy consensus cannot be reached on such a facility, the
>Technical Committee should decide based on the project's wishes as
>expressed in this GR.

This all sounds workable to me as a Policy editor.

>  * Negative general comments about software and their communities,
>including both about systemd itself and about non-systemd init
>systems, are strongly deprecated.

This sense of deprecated is (I think) en_UK, or at least it reads oddly to
this en_US reader.  I'm mentally translating it as "discouraged," but I
wonder if something like "are not acceptable within the Debian Project"
might be closer to the meaning you're intending.

-- 
Russ Allbery (r...@debian.org)  

Re: [draft] Draft text on Init Systems GR

[Sam Hartman]

Ian, first, thanks for a really great and constructive proposal.
I'm assuming you plan to propose this as an amendment and get seconds.

There's one area where I'm hoping you can come up with different
wording, because at least for me, your current wording fails at being
excellent to each other.

>It is also for maintainers of
>   non-default init systems, and the surrounding community, to decide
>   what level of compromised functionality is acceptable to users of
>   non-default init systems.



Every time I read that, I hear that the non-default init system
community wants to be able to block other people's work until they are
satisfied that the level of functionality is not too compromised.

My understanding is that you are not actually trying to do that.
So, if you are not trying to block other people, but instead are trying
to avoid having non-default init users blocked can we find wording that
is more clear?
My emotional reaction to your current wording is really strong and
negative.  That's true even though I think I know what you're trying to
say and have spent significant time trying to reduce my reaction.

Even if you are trying to block other people's work, there is probably
wording that at least for me doesn't get such a strong emotional
response.


signature.asc
Description: PGP signature

Re: [draft] Draft text on Init Systems GR

[Wouter Verhelst]

On Thu, Nov 14, 2019 at 06:36:53PM +, Ian Jackson wrote:
> CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED
> 
>  * Failing to support non-systemd systems when such support is
>available, or offered in the form of patches (or packages),
>*should* be treated as a release critical bug.  For example: init
>scripts *must not* be deleted merely because a systemd unit is
>provided instead; patches which contribute support for other init
>systems should be filed as bugs with severity `serious'.
> 
>This is intended to provide a lightweight but effective path to
>ensuring that reasonable support can be provided to Debian users,
>even where the maintainer's priorities lie elsewhere.  (Invoking
>the Technical Committee about individual patches is not sensible.)
> 
>If the patches are themselves RC-buggy (in the opinion of,
>initially, the maintainer, and ultimately the Release Team) then of
>course the bug report should be downgraded or closed.

The problem with this is that it, essentially, promotes drive-by
patching: someone would like to use a program, but it doesn't come with
support for their init system.

So they write that support, test it perfunctorily (enough for their use
case), and file a bug against the package. The maintainer is now
required to include it, because RC.

But let's assume there's a critical bug in the support they wrote.
Something that during the right phase of the moon could eat data.
That's RC, too.

Who's supposed to fix that bug now?

The package's maintainers? They don't have the setup to test the patch.
That seems unfair.

The person who filed the data-eating bug? What's to say they even have
the skills to do that? That doesn't seem fair, either.

The person who initially wrote the support would be ideal, but they are
now unavailable.

The maintainer is now forced to choose between dropping the support
again, resulting in (most likely) another attempt; investing a lot of
time in fixing the bug; or leaving it unpatched (and allowing for their
users to have their data eaten).

I think a better solution is to accept that some maintainers simply
won't have the time or inclination to maintain support for non-default
init systems, and that such init scripts (or whatever) should therefore
be packaged separately from the main package, maintained by someone who
actually uses the init system in question.

That would also fit well with...

>  * It is for users and maintainers of non-default init systems, and
>the surrounding ecosystem, to test and debug init scripts and other
>aspects of non-systemd support.  It is also for maintainers of
>non-default init systems, and the surrounding community, to decide
>what level of compromised functionality is acceptable to users of
>non-default init systems.

... this.

[...]

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: [draft] Draft text on Init Systems GR

[Ian Jackson]

Sam Hartman writes ("[draft] Draft text on Init Systems GR"):
> This is a draft GR.  I hope to be at a point where I could formally
> propose a GR in a week, assuming discussion converges that fast.

Here is my proposal.  It is unfortunately quite long.  The reason is
that I am trying to address the dysfuncdtional patterns I have seen
over the past few years, and give specific remedies.

-8<-

Title: Support non-systemd systems, without blocking progress

PRINCIPLES

 * We wish to continue to support multiple init systems for the
   foreseeable future.  And we want to improve our systemd support.
   We are disappointed that this has had to involve another GR.

 * It is primarily for the communities in each software ecosystem to
   maintain and develop their respective software - but with the
   active support of other maintainers and gatekeepers where needed.

SYSTEMD DEPENDENCIES

 * Ideally, packages should not Depend on or Recommend systemd, and
   should be fully functional with all init systems.  This means (for
   example) that daemons should ship traditional init scripts, or use
   other mechanisms to ensure that they are started without systemd.
   It also means that desktop software should be installable, and
   ideally fully functional, without systemd.

 * So failing to support non-systemd systems, where no such support is
   available, is a bug.  But it is *not* a release-critical bug.
   Whether the requirement for systemd is recorded as a formal bug in
   the Debian bug system, when no patches are available, is up to the
   maintainer.

 * When a package has reduced functionality without systemd, this
   should not generally be documented as a (direct or indirect)
   Depends or Recommends on systemd-sysv.  This is because with such
   dependencies, installing such a package can attempt to switch the
   init system, which is not the what the user wanted.  For example, a
   daemon with only a systemd unit file script should still be
   installable on a non-systemd system, since it could be started
   manually.

   One consequence of this is that on non-systemd systems it may be
   possible to install software which will not work, or not work
   properly, because of an undeclared dependency on systemd.  This is
   unfortunate but trying to switch the user's init system is worse.
   We hope that better technical approaches can be developed to
   address this.

 * We recognise that some maintainers find init scripts a burden and
   we hope that the community is able to find ways to make it easier
   to add support for non-default init systems.  Discussions about the
   design of such systems should be friendly and cooperative, and if
   suitable arrangements are developed they should be supported in the
   usual ways within Debian.

CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED

 * Failing to support non-systemd systems when such support is
   available, or offered in the form of patches (or packages),
   *should* be treated as a release critical bug.  For example: init
   scripts *must not* be deleted merely because a systemd unit is
   provided instead; patches which contribute support for other init
   systems should be filed as bugs with severity `serious'.

   This is intended to provide a lightweight but effective path to
   ensuring that reasonable support can be provided to Debian users,
   even where the maintainer's priorities lie elsewhere.  (Invoking
   the Technical Committee about individual patches is not sensible.)

   If the patches are themselves RC-buggy (in the opinion of,
   initially, the maintainer, and ultimately the Release Team) then of
   course the bug report should be downgraded or closed.

 * It is for users and maintainers of non-default init systems, and
   the surrounding ecosystem, to test and debug init scripts and other
   aspects of non-systemd support.  It is also for maintainers of
   non-default init systems, and the surrounding community, to decide
   what level of compromised functionality is acceptable to users of
   non-default init systems.

NON-INIT-RELATED DECLARATIVE SYSTEMD FACILITIES

 * systemd provides a variety of facilities besides daemon startup.
   For example, creating system users or temporary directories.
   Current Debian approaches are often based on debhelper scripts.

   In general more declarative approaches are better.  Where
 - systemd provides such facility
 - a specification of the facility (or suitable subset) exists
 - the facility is better than the other approaches available
   in Debian, for example by being more declarative
 - it is reasonable to expect developers of non-systemd
   systems including non-Linux systems to implement it
 - including consideration of the amount of work involved
   the facility should be documented in Debian Policy (by textual
   incorporation, not by reference to an external document).  The
   transition should be smooth for all users.  The non-systemd
   

adding more topics to this GR (Re: [draft] Draft text on Init Systems GR)

[Ian Jackson]

Holger Levsen writes ("adding more topics to this GR (Re: [draft] Draft text on 
Init Systems GR)"):
> On Thu, Nov 14, 2019 at 05:31:19PM +, Ian Jackson wrote:
> > Issue 4.  Hateful stuff on our lists etc.
> > 
> > I have tried to capture what kinds of statements are the key problem
> > here.  I think we need to clearly tell our listmasters etc. what we
> > expect, since enforcement action they take needs clear legitimacy.
> 
> I very well see how this is something we ought to address (at some time,
> maybe even now), but I'm really not convinced (over-)loading the already
> overloaded init system GR with listmaster policying stuff is wise. *Please*
> reconsider.

Well, I am about to post my draft, and we'll see if you still think
it's out of place.  I hope you will come round to agreeing that what I
have said is obviously right.  If it is significantly controversial I
would want to delete it.

Certainly it has come out rather long.  This is unfortunate but it
seems that mere generalities are not really sufficient.  We need some
specifics.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: [draft] Draft text on Init Systems GR

[Wouter Verhelst]

On Thu, Nov 14, 2019 at 04:16:58PM +, Ian Jackson wrote:
> Wouter Verhelst writes ("Re: [draft] Draft text on Init Systems GR"):
> > You can formally propose a GR today, and I recommend you do -- otherwise
> > we end up discussing things before the discussion period, and then you
> > need to sit and wait at least seven days during the *actual* discussion
> > period for no good reason.
> 
> I see what you mean, but respectfully, I disagree.  There is no real
> hurry about this - it is a long-term thing.  It is worth taking the
> time to not just get the options right, but also keep everyone
> comfortable.

Sure.

> In particular, if the DPL were to formally propose a GR, everyone who
> wanted another option on the ballot would immediately be on the clock:
> we would have to get our alternative either agreed with the DPL, or
> seconded, within 7 days, if we wanted to be sure.

Strictly speaking, this is correct.

Having said that though, I would expect a DPL who proposes a GR to not
call for a vote (even though they would be allowed to do so) when people
are still drafting alternate options and/or amendments.

Additionally, the DPL has the ability to vary the discussion period in
*both* directions. Rather than shortening it to 7 days, they can also
lengthen it to 3 weeks.

> Given the febrile atmosphere that some of these systemd discussions
> generate I think we want at the very least the process to avoid any
> hint of anything that feels threatening.

Such a DPL could state the above in public, to clarify that they're not
going to hurry anyone -- but that this is something they want to see
happen (at some point in the reasonably close future).

> I also agree with the people who suggested that it would be best if
> options were drafted by people who actually agree with them.

This is the core of my argument, yes. I don't think that it is useful
for anyone (DPL or otherwise) to propose a GR with more options than
what they themselves would want to vote for.

(there is a difference between drafting an option and seconding one in
this regard though)

> It is of course helpful of the DPL to guide that process, but
> ultimately the way the governance system is supposed to work is that
> people put forward their _own_ options.

Exactly; and I did not feel like that was happening here.

Anyway, I also understand what Sam is trying to do, and I would rather
not sound like a whiner, so this'll be the last bit I'll say about this
;-)

[...]
-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: [draft] Draft text on Init Systems GR

[Wouter Verhelst]

On Mon, Nov 11, 2019 at 08:58:52AM -0500, Sam Hartman wrote:
> > "Wouter" == Wouter Verhelst  writes:
> Wouter> Oh, right. Okay. I suppose that makes sense; the nbd-client
> Wouter> init script hasn't been touched since I wrote the nbd-client
> Wouter> systemd unit, and so I can't really guarantee that it will
> Wouter> work very well anymore.
> 
> Wouter> I guess I was misunderstanding what Sam was writing
> Wouter> initially; I thought he just meant that "if you do early
> Wouter> boot, then we don't care about other init systems", which
> Wouter> seems like it would make the whole point moot.
> 
> Wouter> Perhaps
> Wouter> rather than that, the GR should say something like:
> 
> Wouter> "Due to the higher level of complexity inherent to
> Wouter> early-boot services, it is expected that the init scripts
> Wouter> (or equivalent) for services initialized during early boot
> Wouter> be maintained by the maintainers of the init system in
> Wouter> question, rather than by the maintainers of the service's
> Wouter> package"
> 
> I like this  sentence, and if we get significant support from those who
> favor choice 1, I would accept that amendment.
> Meanwhile, I think I can go as far as
> 
> >Policy notes that early boot services like those started from
> >/etc/rcS.d may be tied closely to the init system in use and thus may
> >need to be handled differently for each init system
> 
> well within the spirit of the current choice 1.

That is definitely clearer, yes.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

adding more topics to this GR (Re: [draft] Draft text on Init Systems GR)

[Holger Levsen]

On Thu, Nov 14, 2019 at 05:31:19PM +, Ian Jackson wrote:
> Issue 4.  Hateful stuff on our lists etc.
> 
> I have tried to capture what kinds of statements are the key problem
> here.  I think we need to clearly tell our listmasters etc. what we
> expect, since enforcement action they take needs clear legitimacy.

I very well see how this is something we ought to address (at some time,
maybe even now), but I'm really not convinced (over-)loading the already
overloaded init system GR with listmaster policying stuff is wise. *Please*
reconsider.

(and please excuse my brevity.)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Re: [draft] Draft text on Init Systems GR

[Ian Jackson]

Sam Hartman writes ("[draft] Draft text on Init Systems GR"):
> This is a draft GR.  I hope to be at a point where I could formally
> propose a GR in a week, assuming discussion converges that fast.

I don't think these options really answer the key questions clearly.

I am going to propose a draft text, but for now I will write what I
think are the four key issues:


Issue 1.  What about init scripts ?  Do maintainers have to write init
scripts ?  What if we don't have an init script ?

Right now not having an init script is nominally an RC bug, although
no-one is filing these bugs.  I think this is largely because just
filing RC bugs is just fighting.  It doesn't lead to any good outcome.

I have a suggestion which might be radical for Debian but seems to
deal with this nicely:

Lack of an init script is a bug, the same way lack of a manpage is
(etc. etc.)  Mostly we don't even file these bugs.

But it is an *RC bug if the bug provides a patch*.  (There are some
details to be dealt with here, eg what if the patch is broken.)

This would encourage people to submit patches, if they care.  If you
could submit a patch with RC severity and knew that that severity was
the project's will, you could expect the maintainer to apply it; if
the maintainer was away or whatever you could NMU it.

OTOH it discourages the useless approach of just filing bugs without
patches.

(We don't need to do the same thing with manpages because maintainers
just apply manpage patches.  No-one is trying to abolish manpages yet,
at least not enough to reject manpage patches.)


Issue 2.  What about non-directly-pid-1-related systemd features like
tmpfiles.d, sysusers.d ?

We are currently using dh stuff for this mostly.  That results in
scripts in packages.  Over the many years we have singularly failed to
make declarative features in dpkg for this, or indeed in anything
else.

I *do* like the idea of declarative syntax.  The difficulties for
non-systemd systems, with many of these features, are not inherent.
Often the specifications don't depend on systemd as pid 1 or on
logind.  Or they have sensible subsets which would be fine and which
we could adopt.

I guess that the project as a whole wants to move forward on this.  I
think we need to find a way to do it.  There are some obstacles we
need to overcome but I think I have wording that deals with most of
them.

I think it is fair to ask the non-systemd folks (like me) to implement
these interfaces, provided that that's only a reaonable amount of work
and provided that change management is in Debian's hands.


Issue 3.  Blocking behaviours.

I don't want to provide specific references, but I have seen more than
one effectively-content-free RC bug filed against a component of the
non-systemd ecosystem.  There have been some other attempts to get
stuff removed as "obsolete".

And then there is the situation with updating Policy to recognise
systemd as the default, and describe unit files etc., for example.

I am hoping that some general words, and a good majority in a GR, will
help to alleviate these problems.  A show of political will by the
project would probably make it difficult to sustain these kind of
blocks.


Issue 4.  Hateful stuff on our lists etc.

I have tried to capture what kinds of statements are the key problem
here.  I think we need to clearly tell our listmasters etc. what we
expect, since enforcement action they take needs clear legitimacy.


Ian.

Re: [draft] Draft text on Init Systems GR

[Ian Jackson]

Wouter Verhelst writes ("Re: [draft] Draft text on Init Systems GR"):
> You can formally propose a GR today, and I recommend you do -- otherwise
> we end up discussing things before the discussion period, and then you
> need to sit and wait at least seven days during the *actual* discussion
> period for no good reason.

I see what you mean, but respectfully, I disagree.  There is no real
hurry about this - it is a long-term thing.  It is worth taking the
time to not just get the options right, but also keep everyone
comfortable.

In particular, if the DPL were to formally propose a GR, everyone who
wanted another option on the ballot would immediately be on the clock:
we would have to get our alternative either agreed with the DPL, or
seconded, within 7 days, if we wanted to be sure.  Given the febrile
atmosphere that some of these systemd discussions generate I think we
want at the very least the process to avoid any hint of anything that
feels threatening.

I also agree with the people who suggested that it would be best if
options were drafted by people who actually agree with them.  It is of
course helpful of the DPL to guide that process, but ultimately the
way the governance system is supposed to work is that people put
forward their _own_ options.

Whether it's helpful of the DPL to *start* this process is not so
clear to me.

But I do think we as a project as a whole have a problem here and it
is possible that another GR would help.  We have some outstanding
examples of cooperation and excellence, such as this one
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944190
Real work is being done and progress is being made.  But we also
have a very toxic atmosphere in some of our mail threads, and
unfortunate blocking behaviours.  (I won't give examples of those
since I don't want to turn the discussion into recriminations.)

I think what we are missing is a common understanding of the ground
rules of behaviour.  To my mind the basic principle of those ground
rules is that people should be allowed to work on what they want to,
within Debian.

It's no difference in principle whether it's a different init system,
or a different kernel, or a different libc, or a different desktop, or
a different package build system, or a different text editor.  People
they should be allowed to do their work.  If they need cooperation
from the rest of us, then provided the enthusiasts for whatever-it-is
are doing most of the work, then we should grant that cooperation.

That does not mean that we should support only the lowest common
denominator in our internal interfaces.  Indeed until fairly recently
Debian was leading in the design and deployment of good interfaces to
allow multiple different approaches to coexist.  This is stuff we are
really good at when we put our mind to it.

The political toxicity surrounding this one issue is preventing that.

So I think what we need is to define some practical rules for who gets
to do what, when, and what the consequences will be if certain work
does not get done.

I have a draft text which I will post shortly.

Ian.

Re: [draft] Draft text on Init Systems GR

[Martin Pitt]

Ansgar [2019-11-11 18:41 +0100]:
> Mike Gabriel writes:
> > I agree with that and at the same time think that we (Debian) should
> > do our best at being universal (that's what the upcoming vote is
> > about).
> 
> How so?
> 
> Debian doesn't support multiple libc implementations.  So it's already
> not universal if "universal" requires to always support alternative
> implementations.

That's a rather/too strong definition of "universal", though. From an user's
POV, "universal" means "I can use it for all/most use cases of my computing
needs", i. e. from a smart watch over a cloud instance to a supercomputer. I
don't see these use cases inherently being limited by only having one kernel,
libc, or init system. We also don't have multiple coreutils, udisks, or sed
(for a good reason). To the contrary, that's one of GNU/Linux'es strength --
it's put together in a way that it scales so well.

IMHO, "always supports alternative implementations" equals lose coupling and
(by trend) weaker APIs in between components, and is not always desirable.
"universal" from an application POV *is* desirable for us as a project, but it
doesn't depend on components being replaceable, but that they scale/adjust
enough.

Martin

Re: [draft] Draft text on Init Systems GR

[Russ Allbery]

Bernd Zeimetz  writes:
> On 2019-11-12 18:56, Russ Allbery wrote:

>> Including options in a GR that no one supports is a waste of everyone's
>> time and mental energy.

> How do you know that no one supports that?

I'm not.  That was the point of the rest of my message, which describes
the process that we use for figuring that out.

> I'd second that and I'm sure there are many more out there who would
> do the same.

Then you should propose that formally once the GR process starts so that
we can see if that's what happens.

-- 
Russ Allbery (r...@debian.org)  

Re: [draft] Draft text on Init Systems GR

[Holger Levsen]

On Wed, Nov 13, 2019 at 02:59:51PM +0100, Matthias Klumpp wrote:
> Exactly this. I think I would definitely second a "focus on systemd"
> amendment which makes packages support systemd as a priority, but
> doesn't force out sysvinit or any other init system from the archive.
> I think there's a valid point in having them, and as long as they
> don't impair the default init system and people aren't forced to do
> work they can't test, it's fine to have them.

indeed.

> So, something like this maybe? (adapted from Alexander E. Patrakov's text):
> ```
> Choice 4: Focus on systemd as init system and features requiring it
> 
> The Debian project recognizes that systemd service units are nowadays
> the preferred configuration for describing how to start a daemon/service.
> Packages should include service units. At the same time,
> the Debian project acknowledges that maintainers and upstream developers
> are often unable to provide high-quality (or any) support for alternative
> init systems in their packages on their own and can not or do not test
> that their
> packages work under such init systems. It is not realistic to expect
> the situation to improve, and Debian does not want to block
> experimentation with new Linux-based technologies developed under the
> systemd project umbrella or hinder their adoption by requiring all
> other init systems to support the same features as well (which may not
> even be desired by those projects).
> Therefore, Debian should focus on a polished experience with systemd
> as init system as first priority. Other init systems will remain
> available as long as there is enough interest by people to maintain
> them. Package maintainers are encouraged to accept patches to support
> non-systemd configurations, as long as the changes do not impair the
> user experience when systemd is available. Package maintainers may
> split out support for alternative init systems into separate binary
> packages. Maintainers of other init systems are encouraged to test
> support for their configurations if the package maintainer can not do
> it.
> 
> Debian is still committed to working with derivatives that make
> different choices about init systems.
> ```
> This would mean that it's not a bug if no sysvinit script is provided
> by a package and only a systemd unit is available. Also, if a sysvinit
> script is faulty, such an issue would be a normal/important bug and
> wouldn't get a package removed or excluded from release. At the same
> time, maintainers of alternative init systems could add support for
> their systems, as long as they test it (CI/autopkgtest may help
> there).
> Any alternative init system would very much be second-class, but so
> are alternative kernels, or compilers, or libc implementations, or
> architectures (or desktop environments, some would argue), and that
> doesn't stop people from doing awesome work on them. And if we ever
> want to switch away from systemd to something else, we still could -
> but until then, the experience with it should be as good as we can
> possibly make it.
> 
> This is not a finished proposal, but something I would be much more
> likely get behind compared to a "systemd and completely screw
> everybody who wants something else by policy" approach.

many thanks for writing this up. I'd second such an amendment. With two
small changes:

- s#This would mean that it's not a bug if no sysvinit script is \
  provided#This would mean that it's not an important (or higher) \
  bug if no sysvinit script is provided#
- s#normal/important bug#norma bug#


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Re: [draft] Draft text on Init Systems GR

[Matthias Klumpp]

Am Mi., 13. Nov. 2019 um 11:55 Uhr schrieb Holger Levsen
:
>
> On Tue, Nov 12, 2019 at 09:51:03PM +0500, Alexander E. Patrakov wrote:
> > Choice 4: systemd without Diversity at all
>
> as said before, I dislike the 'without diversity' framing and think it's
> wrong, misleading and insulting. So I'd rather propose 'focus our efforts
> on systemd' or 'systemd and overcoming technical debt' or whatever.
>
> systems running systemd vary a lot and have a *lot* diversity.
>
> similarily I would also *not* call sysv bad names or frame it badly.
> (and maybe even calling it 'technical debt' is not a good idea.)

Exactly this. I think I would definitely second a "focus on systemd"
amendment which makes packages support systemd as a priority, but
doesn't force out sysvinit or any other init system from the archive.
I think there's a valid point in having them, and as long as they
don't impair the default init system and people aren't forced to do
work they can't test, it's fine to have them.

So, something like this maybe? (adapted from Alexander E. Patrakov's text):
```
Choice 4: Focus on systemd as init system and features requiring it

The Debian project recognizes that systemd service units are nowadays
the preferred configuration for describing how to start a daemon/service.
Packages should include service units. At the same time,
the Debian project acknowledges that maintainers and upstream developers
are often unable to provide high-quality (or any) support for alternative
init systems in their packages on their own and can not or do not test
that their
packages work under such init systems. It is not realistic to expect
the situation to improve, and Debian does not want to block
experimentation with new Linux-based technologies developed under the
systemd project umbrella or hinder their adoption by requiring all
other init systems to support the same features as well (which may not
even be desired by those projects).
Therefore, Debian should focus on a polished experience with systemd
as init system as first priority. Other init systems will remain
available as long as there is enough interest by people to maintain
them. Package maintainers are encouraged to accept patches to support
non-systemd configurations, as long as the changes do not impair the
user experience when systemd is available. Package maintainers may
split out support for alternative init systems into separate binary
packages. Maintainers of other init systems are encouraged to test
support for their configurations if the package maintainer can not do
it.

Debian is still committed to working with derivatives that make
different choices about init systems.
```
This would mean that it's not a bug if no sysvinit script is provided
by a package and only a systemd unit is available. Also, if a sysvinit
script is faulty, such an issue would be a normal/important bug and
wouldn't get a package removed or excluded from release. At the same
time, maintainers of alternative init systems could add support for
their systems, as long as they test it (CI/autopkgtest may help
there).
Any alternative init system would very much be second-class, but so
are alternative kernels, or compilers, or libc implementations, or
architectures (or desktop environments, some would argue), and that
doesn't stop people from doing awesome work on them. And if we ever
want to switch away from systemd to something else, we still could -
but until then, the experience with it should be as good as we can
possibly make it.

This is not a finished proposal, but something I would be much more
likely get behind compared to a "systemd and completely screw
everybody who wants something else by policy" approach.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: [draft] Draft text on Init Systems GR

[Holger Levsen]

On Tue, Nov 12, 2019 at 09:51:03PM +0500, Alexander E. Patrakov wrote:
> Choice 4: systemd without Diversity at all
 
as said before, I dislike the 'without diversity' framing and think it's
wrong, misleading and insulting. So I'd rather propose 'focus our efforts
on systemd' or 'systemd and overcoming technical debt' or whatever.

systems running systemd vary a lot and have a *lot* diversity.

similarily I would also *not* call sysv bad names or frame it badly.
(and maybe even calling it 'technical debt' is not a good idea.)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Re: [draft] Draft text on Init Systems GR

[Andrey Rahmatullin]

On Wed, Nov 13, 2019 at 11:46:27AM +0100, Bernd Zeimetz wrote:
> > > I think that one choice is missing here. Could you please include
> > > something like this, just to see how many people are THAT radical?
> > > P.S. myself, I wouldn't vote for this even if I had a vote.
> > 
> > > Choice 4: systemd without Diversity at all
> > 
> > Including options in a GR that no one supports is a waste of everyone's
> > time and mental energy.
> 
> How do you know that no one supports that?
> I'd second that and I'm sure there are many more out there who would
> do the same. Imho all other options are wasted time at the end.
I think the idea is "only propose an option if you are willing to vote for
it", so it should be an amendment, not one of the initial options.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: [draft] Draft text on Init Systems GR

[Bernd Zeimetz]

On 2019-11-12 18:56, Russ Allbery wrote:

"Alexander E. Patrakov"  writes:


I think that one choice is missing here. Could you please include
something like this, just to see how many people are THAT radical?
P.S. myself, I wouldn't vote for this even if I had a vote.



Choice 4: systemd without Diversity at all


Including options in a GR that no one supports is a waste of everyone's
time and mental energy.


How do you know that no one supports that?
I'd second that and I'm sure there are many more out there who would
do the same. Imho all other options are wasted time at the end.



--
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: [draft] Draft text on Init Systems GR

[Alexander E. Patrakov]

[Disclaimer: I am not a Debian Developer so have no formal power to 
propose anything.]


Sam Hartman wrote:

Choice 1: Affirm Init Diversity
Choice 2: systemd but we Support Exploring Alternatives
Choice 3: systemd  without Diversity as a Priority


I think that one choice is missing here. Could you please include 
something like this, just to see how many people are THAT radical? P.S. 
myself, I wouldn't vote for this even if I had a vote.


Choice 4: systemd without Diversity at all

The Debian project recognizes that systemd service units are nowadays 
the preferred configuration for describing how to start a 
daemon/service. Packages should include service units. At the same time, 
the Debian project recognizes that maintainers and upstream developers 
are sometimes unwilling or unable to provide high-quality support (or 
any support) for alternative init systems in their packages, do not test 
that their packages work under such init systems, and it is not 
realistic to expect the situation to improve. Allowing substandard 
support for non-systemd init systems would be against the project goals, 
worse than no support at all. Therefore, for Bullseye, alternative init 
systems should be removed from the archive together with everything that 
becomes useless due to that, e.g. initscripts that have an equivalent 
systemd unit.


Debian is still committed to working with derivatives that make 
different choices about init systems.


--
Alexander E. Patrakov

Re: [draft] Draft text on Init Systems GR

[Ansgar]

Mike Gabriel writes:
> On  Sa 09 Nov 2019 23:57:08 CET, Matthias Klumpp wrote:
>> The one thing I am against though is the non-Linux ports holding back
>> innovation and experimentation on the Linux ports. If we go with the
>> lowest common denominator, we can't realistically move forward, ever.
>
> I agree with that and at the same time think that we (Debian) should
> do our best at being universal (that's what the upcoming vote is
> about).

How so?

Debian doesn't support multiple libc implementations.  So it's already
not universal if "universal" requires to always support alternative
implementations.  Nor does Debian (the released distribution) support
non-Linux kernels.  Nor does Debian support the various OpenSSL forks.

We also have lots of software that requires Linux-specific functions and
are not portable.

So in many, many cases Debian has made the choice to only support one
specific implementation of something.

Ansgar

Re: [draft] Draft text on Init Systems GR

[Mike Gabriel]

Hi Matthias,

On  Sa 09 Nov 2019 23:57:08 CET, Matthias Klumpp wrote:


Am Sa., 9. Nov. 2019 um 23:01 Uhr schrieb Mike Gabriel
:

[...]
Isn't as side-question that is on the table with this GR: what about
the future of non-Linux variants of Debian. If systemd becomes _the_
init system of focus in Debian (by vote, not only de facto), kFreeBSD
and Hurd will certainly have more of their difficulties, more than
they have now.
[...]



[...]



The one thing I am against though is the non-Linux ports holding back
innovation and experimentation on the Linux ports. If we go with the
lowest common denominator, we can't realistically move forward, ever.


I agree with that and at the same time think that we (Debian) should  
do our best at being universal (that's what the upcoming vote is about).


Greets,
Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpxvTxwbfvu8.pgp
Description: Digitale PGP-Signatur

Re: [draft] Draft text on Init Systems GR

[Sam Hartman]

> "Wouter" == Wouter Verhelst  writes:
Wouter> Oh, right. Okay. I suppose that makes sense; the nbd-client
Wouter> init script hasn't been touched since I wrote the nbd-client
Wouter> systemd unit, and so I can't really guarantee that it will
Wouter> work very well anymore.

Wouter> I guess I was misunderstanding what Sam was writing
Wouter> initially; I thought he just meant that "if you do early
Wouter> boot, then we don't care about other init systems", which
Wouter> seems like it would make the whole point moot.

Wouter> Perhaps
Wouter> rather than that, the GR should say something like:

Wouter> "Due to the higher level of complexity inherent to
Wouter> early-boot services, it is expected that the init scripts
Wouter> (or equivalent) for services initialized during early boot
Wouter> be maintained by the maintainers of the init system in
Wouter> question, rather than by the maintainers of the service's
Wouter> package"

I like this  sentence, and if we get significant support from those who
favor choice 1, I would accept that amendment.
Meanwhile, I think I can go as far as

>Policy notes that early boot services like those started from
>/etc/rcS.d may be tied closely to the init system in use and thus may
>need to be handled differently for each init system

well within the spirit of the current choice 1.

I'd definitely like to resolve this ambiguity.  All I'm trying to do is
accurately summarize policy/our thinking on this issue in that
sentence.  That sentence is not even intended to make any changes, but
calling out this point was important to Martin.

Re: [draft] Draft text on Init Systems GR

[Sam Hartman]

This is a reply to multiple messages.
I know it's long, I don't see a way to avoid that.
Search for lines of equal signs (=) to split issues I'm replying to.


Working with Downstreams


So, a couple of people have commented on the commitment to work with
downstreams in choice 2 and 3.

Here's what that commitment means to me.
It means that we'll work with derivatives to figure out where the
boundary is between their derivative and Debian.  We (particularly the
DPL) will be responsive to questions about where that boundary is.  When
it is not obvious, that may involve discussion on -project or -devel.

Let's take choice 3 as an example.

* Devuan reports a bug in dpkg independent of init systems that they can
reproduce on Debian.  We're happy to take their bug report.

* They don't get a response in the time frame they are hoping for.  They
write to the DPL.  (the DPL does sometimes get messages from people
outside the community hoping for help in getting things to move
faster).  The DPL looks at the issue and decides how much of their time
they want to invest.  Perhaps the DPL writes a polite note explaining
that Debian developers are all volunteers.  Perhaps the DPL prods the
dpkg maintainer and asks if there's any way it can move faster.  Perhaps
the DPL gives a suggestion on how Devuan can make the bug report more
useful (better test case, comments about a patch).  Perhaps the DPL
solicits someone in the Debian community to do the above.

* Devuan wonders whether it still makes sense for them to submit patches
to packages including init scripts under choice 3.  We have a discussion
on -devel and if there is a consensus let them know what it is.

* A derivative writes to us asking if we'd consider a patch to make
things easier in some way when not running systemd.  We review the patch
just as we would (and just as [in]efficiently) other patch submissions
we get.

Under choice 2:

One of the reasons that I started looking into this was requests I got
from people inside Devuan about challenges with elogind in Debian.  It
turns out I got the same request with people involved in maintaining
elogind inside Debian too, and I focused on that side of the request
more than the Devuan request.  I didn't understand the project consensus
on how much we value elogind enough to understand what I should do.
Some of the feedback I got from within Debian was that sysvinit was dead
and people were not reviewing patches/engaging with elogind issues
because they hoped it would go away.
If the project supports choice 3, that's a fine response.  If we support
choice 1 or choice 2, that's not a great response from someone who is in
a gatekeeper role.

In my mind commitment to work with downstreams is far more about letting
them know how they can interact with Debian and what they can expect.
It is not a promise to do any particular thing, more a commitment to
keep communication lines open.

Choice 1 Policy Language

> "Ansgar" == Ansgar   writes:

>> Choice 1: Affirm Init Diversity
>> 
>> Being able to run Debian systems with init systems other than
>> systemd continues to be something that the project values.  With
>> one exception, the Debian Project affirms the current policy on
>> init scripts and starting daemons (policy 9.3.2, 9.11).

Ansgar> I would not recommend referring to the "current policy" as
Ansgar> it is unclear
Ansgar> what that is.  

I understand your concern.
I'd be delighted to work with proponents of init system diversity to
reword choice 1 without referring to current policy language if that's
something they want to do.
And certainly anyone can propose an amendment to that effect.

My rationale for choice 1 as it stands today is that I've gotten
significant feedback from some people that they want a status quo option
in terms of the current policy.  I did have enough discussions with Russ
that I think the summary in choice 1 of what current policy means is
fairly accurate.  If we get the right people engaged in a discussion of
rewording choice 1, I think it would be great.



> "Holger" == Holger Levsen  writes:

Constitutional Basis


Holger> I fail to see why Constitution section 4.1 (5) is referred
Holger> here. I'd better understand section 4.1 (4) and would
Holger> probably would prefer to leave out this half sentence
Holger> completly.

The secretary has expressed a preference for making it clear what
constitutional power  is used when proposing a resolution.  That was in
a TC context, but I think applies equally here.

I prefer 4.1(5) to 4.1 (4) for a couple of reasons.  TFor those who
don't have the constitution memorized we're debating whether to make a
statement of the day (4.1 (5)) or to make a decision under TC power (4.1
(4)).  A statement of the day is less forceful; it doesn't have any
formal power.  It lets us understand consensus, but allows maintainers
and 

Re: ***UNCHECKED*** Re: [draft] Draft text on Init Systems GR

[Simon Richter]

Hi,

On Sun, Nov 10, 2019 at 12:19:24AM +0100, Bernd Zeimetz wrote:

> > Yes, that would be my desired outcome: an affirmation that Debian wants to
> > be "universal". This has been our greatest strength for years.

> Its a strength that wasted an enormous  amount of ressources. See
> kfreebsd (which was actually really nice!) and Hurd, to name some
> prominent examples.

Taking this to the extreme, it is an enormous waste of resources to
maintain both Debian and Ubuntu as separate entities. What differentiates
us?

> People should not be forced to waste their time, but also we should not
> necessarily stop them if they want to do it.

The problem is at the intersection when one person considers it a waste of
their time when they are asked to integrate the work of another person,
whose work is wasted if it is not integrated.

> For me I think the only useful way would be to maintain all init-scripts
> in a single package that gets pulled in with sysvinit. Whoever wants to
> use and maintain it is free to do so. Initscript could actually be
> installed using dpkg triggers or whatever else works.

You are still missing the point. This is not a technical problem, and
providing a technical solution...

> (And at some time we can still move that package into an external
> repository).

... that essentially tells people to leave the project if they disagree
with you is not a solution for a social problem, quite the opposite in
fact.

   Simon

Re: [draft] Draft text on Init Systems GR

[Bernd Zeimetz]

On 11/9/19 11:24 PM, Simon Richter wrote:

> Yes, that would be my desired outcome: an affirmation that Debian wants to
> be "universal". This has been our greatest strength for years.

Its a strength that wasted an enormous  amount of ressources. See
kfreebsd (which was actually really nice!) and Hurd, to name some
prominent examples.

People should not be forced to waste their time, but also we should not
necessarily stop them if they want to do it.

For me I think the only useful way would be to maintain all init-scripts
in a single package that gets pulled in with sysvinit. Whoever wants to
use and maintain it is free to do so. Initscript could actually be
installed using dpkg triggers or whatever else works.

(And at some time we can still move that package into an external
repository).

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: [draft] Draft text on Init Systems GR

[Matthias Klumpp]

Am Sa., 9. Nov. 2019 um 23:01 Uhr schrieb Mike Gabriel
:
> [...]
> Isn't as side-question that is on the table with this GR: what about
> the future of non-Linux variants of Debian. If systemd becomes _the_
> init system of focus in Debian (by vote, not only de facto), kFreeBSD
> and Hurd will certainly have more of their difficulties, more than
> they have now.
> [...]

This comes up often, but I don't think this is actually that big of a
deal: kFreeBSD & Co. already require a lot of other changes in
packages, related to facilities (DBus services, syscalls, etc.) not
available on these platforms.
While all Linux ports could use systemd, the kFreeBSD/Hurd
architectures could continue using sysvinit, and packages could
conditionally install init-scripts only on the kFreeBSD architecture.
This also avoids dependency issues and problems caused by switching
out init.

Note that I am not saying "this is what should be done", just that in
case we *would* go all-in on systemd, this in no way would mean the
death of non-Linux ports. Sure, they would be slightly harder to
maintain, but they are already a hard thing to do, and compared to
porting stuff that uses Linux syscalls, the init issue isn't that much
different.

The one thing I am against though is the non-Linux ports holding back
innovation and experimentation on the Linux ports. If we go with the
lowest common denominator, we can't realistically move forward, ever.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: [draft] Draft text on Init Systems GR

[Simon Richter]

Hi Mike,

On Sat, Nov 09, 2019 at 09:48:03PM +, Mike Gabriel wrote:

> root@minobo:~# apt-rdepends -r systemd | wc -l

> 6598

It's not as bad as you think: the important package is systemd-sysv.

In buster:
$ apt-cache rdepends systemd-sysv


In bullseye:
systemd-sysv
Reverse Depends:
  systemd-cron
  dbus-user-session
 |xfce4-session
 |unattended-upgrades
  sysvinit-core
  sysvinit-core
  libvirt-daemon-system
  udev
  libpam-systemd
  runit-systemd
  runit-init
  runit-init
  prometheus-postgres-exporter
  prometheus-node-exporter
  prometheus-bind-exporter
  prometheus-apache-exporter
  prometheus-alertmanager
  prometheus
  profile-sync-daemon
  pk4
 |numad
  munin
  micro-httpd
  mender-client
 |mandos
  logrotate
  dbus-user-session
 |libguestfs0
 |init
  gpsd
  friendly-recovery
  exim4-base

The lines marked with a | have an alternative, e.g. numad has

..., systemd-sysv | cgmanager, ...

Several of these are not Depends, but Conflicts/Replaces relationships, but
I have no idea how to quickly filter them, and several like exim4-base have
alternatives, but these aren't shown here.

What I can confirm depends on systemd-sysv are

 - systemd-cron (not relevant, we have cron)
 - dbus-user-session (can be replaced by dbus-x11, although apt doesn't
   find that solution)
 - libvirt-daemon-system (real problem)
 - udev (not relevant, we have eudev)
 - libpam-systemd (not relevant, that is the integration for
   dbus-user-session & co)

So the only real issues at the moment are libvirt-daemon-system and apt
needing a manual poke when installing something that pulls in
dbus-user-session, such as libgtk.

   Simon

Re: [draft] Draft text on Init Systems GR

[Mike Gabriel]

Hi,

On  Do 07 Nov 2019 19:59:49 CET, Sam Hartman wrote:


No, the difference intended between choice 2 and 3 is about how we
handle technologies like elogind, or a mythical technology that parsed
sysusers files, rather than how we handle starting daemons.


I'd suggest leaving elogind entirely out of the discussion, here.

The elogind fork of the systemd component systemd-logind only kicks  
in, just like systemd-logind, once a user logs into the session.


As I get it, the rest of the GR draft is about system services  
initialization, not user session services startups.


If systemd was mandatory, user session services would be handled by  
systemd-logind.


If systemd was replaceable by some other init system, than there would  
be (at least) two options:


  - still use systemd-logind for user session service startups
(and have all the systemd entanglement package-wise) [1, 2]
  - use elogind (drop-in replacement for systemd-logind, no entanglement
with systemd as a system service orchestrator)

Isn't as side-question that is on the table with this GR: what about  
the future of non-Linux variants of Debian. If systemd becomes _the_  
init system of focus in Debian (by vote, not only de facto), kFreeBSD  
and Hurd will certainly have more of their difficulties, more than  
they have now.


light+love,
Mike

[1] in Debian jessie this was possible
[2] Ubuntu used to have a phase when upstart was handling system  
services and systemd-logind was handling user session services


--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpFxlp1eGHIc.pgp
Description: Digitale PGP-Signatur

Re: [draft] Draft text on Init Systems GR

[Mike Gabriel]

On  Sa 09 Nov 2019 19:09:35 CET, Holger Levsen wrote:


On Sat, Nov 09, 2019 at 06:08:54PM +0100, Simon Richter wrote:

(Option 1.1.1)

Automated variant transitions shall be supported.

[Rationale: moving from systemd to sysvinit is currently an involved manual
process, so unavailable to anyone not already skilled in Unix
administration, creating an artificial barrier.]


please clarify what you mean by this. I understand that you claim that
"apt-get install -y sysvinit-core" is hard (I disagree somewhat, but I
also think that those for this is hard shouldn't care) but anyway, what
do you envision how 'automated variant transitions' should be done? A
click in some UI?

(This is a serious question and the reason i'm sending this mail. I'm
really curious as I think
https://wiki.debian.org/systemd#Installing_without_systemd is pretty
clear and easy.)



The problem here is this (queried on a buster system):

```
root@minobo:~# apt-rdepends -r systemd
systemd
  Reverse Depends: 389-ds-base (1.4.0.21-1)
  Reverse Depends: apticron-systemd (1.2.1)
  Reverse Depends: arctica-greeter (0.99.1.3-1)
  Reverse Depends: ayatana-indicator-session (0.4.3-2)
  Reverse Depends: biometric-auth (0.9.61-2)
  Reverse Depends: biometric-utils (0.9.61-2)
  Reverse Depends: btrfsmaintenance (0.4.2-1)
  Reverse Depends: clevis-systemd (11-2)
  Reverse Depends: cloudprint-service (0.14-12)
  Reverse Depends: dbus-user-session (1.12.16-1)
  Reverse Depends: fakemachine (0.0~git20181105.9316584-2)
  Reverse Depends: fcgiwrap (1.1.0-12)
  Reverse Depends: iio-sensor-proxy (2.4-2)
  Reverse Depends: kde-config-systemd (>= 1.2.1-3)
  Reverse Depends: libbiometric-dev (0.9.61-2)
  Reverse Depends: libbiometric0 (0.9.61-2)
  Reverse Depends: liblxc1 (1:3.1.0+really3.0.3-8)
  Reverse Depends: libnss-resolve (= 241-7~deb10u1)
  Reverse Depends: libnss-systemd (= 241-7~deb10u1)
  Reverse Depends: libpam-systemd (= 241-7~deb10u1)
  Reverse Depends: libreswan (3.27-6)
  Reverse Depends: live-config-systemd (5.20190519)
  Reverse Depends: local-apt-repository (0.6)
  Reverse Depends: ltsp-client (>= 5.18.12-3)
  Reverse Depends: mate-power-manager (1.20.3-2)
  Reverse Depends: netplan.io (>= 0.95-2)
  Reverse Depends: ntpsec-ntpviz (1.1.3+dfsg1-2)
  Reverse Depends: oddjob (0.34.4-1)
  Reverse Depends: open-infrastructure-system-config (20190202-1)
  Reverse Depends: openvpn-systemd-resolved (>= 1.2.7-1)
  Reverse Depends: plymouth (>= 0.9.4-1.1)
  Reverse Depends: python-ipalib (4.7.2-3)
  Reverse Depends: rasdaemon (0.6.0-1.2)
  Reverse Depends: snapd (2.37.4-1+b1)
  Reverse Depends: sogo (4.0.7-1)
  Reverse Depends: systemd-container (= 241-7~deb10u1)
  Reverse Depends: systemd-coredump (= 241-7~deb10u1)
  Reverse Depends: systemd-journal-remote (= 241-7~deb10u1)
  Reverse Depends: systemd-tests (= 241-7~deb10u1)
  Reverse Depends: tomcat9 (>= 9.0.16-4)
  Reverse Depends: ukui-power-manager (1.1.2-1)
  Reverse Depends: vblade (24-3)
  Reverse PreDepends: systemd-sysv (241-7~deb10u1)
[...]
```

Output has been shortened to the first layer of the dependency tree.

```
root@minobo:~# apt-rdepends -r systemd | wc -l
Reading package lists... Done
Building dependency tree
Reading state information... Done
6598
```

The previous command would print out 6598 lines, in fact.


We have several packages that hard-depend on systemd. IMHO, all of  
those should be investigated, if such a hard dependency could not be  
avoided. (In fact, arctica-greeter and mate-power-manager could indeed  
live without it). For iio-proxy-sensor, I just did an NMU that dropped  
the hard systemd dependency.



On my local notebook (on buster), a switch to sysvinit-core would to this...

```
root@minobo:~# apt-get install sysvinit-core
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer  
required:
  accountsservice appstream apt-config-icons apt-config-icons-large  
argyll bluefish-data bluefish-plugins bolt brasero-cdrkit  
breeze-cursor-theme caja-common catdoc cinnamon-common  
cinnamon-control-center-data cinnamon-screensaver  
cinnamon-screensaver-x-plugin cinnamon-settings-daemon cjs colord-data  
dvd+rw-tools
  evemu-tools evtest gir1.2-abi-3.0 gir1.2-cinnamondesktop-3.0  
gir1.2-clutter-gst-3.0 gir1.2-cmenu-3.0 gir1.2-cvc-1.0  
gir1.2-dazzle-1.0 gir1.2-gdm-1.0 gir1.2-gnomebluetooth-1.0  
gir1.2-grilo-0.3 gir1.2-gsf-1 gir1.2-keybinder-3.0 gir1.2-mediaart-2.0  
gir1.2-meta-muffin-0.0 gir1.2-mutter-3 gir1.2-packagekitglib-1.0
  gir1.2-pluma-1.0 gir1.2-xapp-1.0 gnome-session-bin  
gnome-session-common growisofs hwdata iso-flags-png-320x240 k3b-data  
kate5-data katepart kde-cli-tools-data kde-style-qtcurve-qt4 kded5  
kdelibs-bin kdoctools kdoctools5 khotkeys-data kio-extras-data  
kpackagetool5 ksysguard-data ksysguardd ktexteditor-data
  kwin-data kwrited libappstream4 libappstreamqt2 libblockdev-fs2  
libblockdev-loop2 libblockdev-part-err2 

Re: [draft] Draft text on Init Systems GR

[Simon Richter]

Hi,

On Sat, Nov 09, 2019 at 10:01:27AM -0800, Russ Allbery wrote:

> > (Option 1)

> > The Debian Project aims at providing the greatest configuration flexibility
> > while maintaining a sensible default installation for end users. To that
> > end, we document functional dependencies in a machine-readable way and
> > provide alternative variants if possible.

> "Functional dependencies" feels odd to me as a way of characterizing this
> whole problem space.  I can kind of see where you're coming from with
> that, but it's about more than dependencies.  It's also about configuring
> the environment in which a service should run and controlling the
> mechanisms of starting the service and determining when it should be
> running.

Yes, but all of these can be boiled down to required interfaces, "can I
express the desired environment and start conditions in the terms of this
interface?"

Interfaces are versioned, however, and we need either a negotiation process
or a mechanism to avoid version mismatch. With a slow-moving interface like
sysvinit's, that was not a problem, but systemd evolves faster than Debian
releases. Negotiation is out for static unit files, so that leaves a
lockout mechanism.

In the "full diversity" case, we'd ideally map the required interfaces onto
package relationships, e.g.

Depends: interface-systemd-timer-unit-1 (>= 4)

Here, 1 and 4 are the version numbers for the interface -- no
compatibility breaks yet, but the unit file uses declarations added in a
later revision. This mechanism could work similar to shared libraries with
symbol versions, and the usual Conflicts/Provides mechanism would make sure
that only one provider for each interface is installed.

Long term, init scripts would lose their special status and require a
dependency declaration as well, which could be used to decide if systemd
generators for init compatibility are needed. A package providing both an
init script and a service unit file would declare that it requires either,
and thus would not force anyone to install compatibility code.

> The phrasing here doesn't really address how aggressive we're going to be
> about using systemd services.  I think "if possible" is doing a bit too
> much heavy lifting and not providing enough guidance.

The default would still remain systemd. Alternative implementations will
only appear if there is interest in having them, so there is no point in
binding the project into providing them with no users.

My expectation is that alternative implementations will pick and choose
what interfaces to implement, based on users' needs and feasibility.
Basically, if the sysvinit users are mostly running system services on
headless boxes, then there is no need to provide an implementation of
dbus-activated session services.

> > (Option 1.1.1)

> > Automated variant transitions shall be supported.

> > [Rationale: moving from systemd to sysvinit is currently an involved
> > manual process, so unavailable to anyone not already skilled in Unix
> > administration, creating an artificial barrier.]

> Doesn't this have that same problem that it votes for creating an RC bug
> that we have no real idea how to fix?

Probably a package that diverts /sbin/init and replaces it with a shell
script that checks if a transition is pending and performs it if all
requirements are met (e.g. required packages available in apt cache and
checksums correct, ...). No need to do this in existing packages.

> In general, for these variants, is the transition path from systemd to
> sysvinit something that is controversial in the project?  I thought the
> problem was mostly ensuring things work on sysvinit at all.

The transition path is important as long as the installer installs systemd
by default and this cannot be changed (which would be option 1.1.3).

The number "1% of new installations use sysvinit" is floating around. In
absolute terms, that is a massive number of people who went through a long
manual process, and making that process less painful would be a great
service.

> > (Option 1.2.1)

> > Package maintainers for packages requiring tighter integration into a
> > particular ecosystem are asked to form teams to cover adequate
> > integration testing.

> I truly have no idea what this means, what Policy language it would
> translate into, or what work this implies a Debian package maintainer
> should do.

As for Policy, not much, since that is an organizational, not a technical
thing.

My expectation is that services that require more complex integration than
"start process (after rcS.d|before multi-user.target)" will be
team-maintained anyway, and this is expressing a wish that if a volunteer
pops up who is using that service on a sysvinit box and they are remotely
competent, they get added to the team as the go-to person for sysvinit
integration. That doesn't necessitate commit access, but likely will, and
it probably implies a mail "I'm about to upload a new upstream release, can
you check if it 

Re: [draft] Draft text on Init Systems GR

[Russ Allbery]

Simon Richter  writes:

> the main problem I see with this GR is that it is in essence a rehash of
> the GR[1] we had in 2014, with pretty much the same options minus the
> one that won, "A GR is not required."

I voted that option in 2014 and definitely will not be voting that option
today, for the reasons explained in another thread on debian-devel.  If
there are a sufficient number of people like myself who feel that way now,
this isn't really a rehash.  It's five years later; some things have
changed and we understand more about the problem space.

> The fact that only service start is documented in policy is a bug in
> itself.

There are numerous bugs in Policy in this area and a truly huge amount of
work that needs to be done.

On to your proposal

> (Option 1)

> The Debian Project aims at providing the greatest configuration flexibility
> while maintaining a sensible default installation for end users. To that
> end, we document functional dependencies in a machine-readable way and
> provide alternative variants if possible.

"Functional dependencies" feels odd to me as a way of characterizing this
whole problem space.  I can kind of see where you're coming from with
that, but it's about more than dependencies.  It's also about configuring
the environment in which a service should run and controlling the
mechanisms of starting the service and determining when it should be
running.

The phrasing here doesn't really address how aggressive we're going to be
about using systemd services.  I think "if possible" is doing a bit too
much heavy lifting and not providing enough guidance.

> (Option 1.1.1)

> Automated variant transitions shall be supported.

> [Rationale: moving from systemd to sysvinit is currently an involved
> manual process, so unavailable to anyone not already skilled in Unix
> administration, creating an artificial barrier.]

Doesn't this have that same problem that it votes for creating an RC bug
that we have no real idea how to fix?

In general, for these variants, is the transition path from systemd to
sysvinit something that is controversial in the project?  I thought the
problem was mostly ensuring things work on sysvinit at all.

> (Option 1.2.1)

> Package maintainers for packages requiring tighter integration into a
> particular ecosystem are asked to form teams to cover adequate
> integration testing.

I truly have no idea what this means, what Policy language it would
translate into, or what work this implies a Debian package maintainer
should do.

> (Option 1.2.3)

> The same software may be packaged multiple times by different
> maintainers if integration requirements cause incompatibilities.

> [Rationale: this allows packaging to be kept simple, at the expense of
> some space in the archive]

This seems fraught with technical peril.  Are we sure our package
dependency resolution code is capable of dealing with this tangle of
Conflicts and Provides?

> (Option 2)

> The Debian project aims at providing a tightly integrated operating
> system, standardizing on specific components to ensure the availability
> of basic functionality.

I think it would be interesting to have this sort of "all in on systemd"
option on the ballot to understand how many people in the project may feel
this way but be unwilling to wade into the interminable threads, although
it feels kind of aggressive as only one of two choices.

Also, I think that if this is about standardizing on systemd, we should
just say that, as opposed to speaking in generic terms.

> (Option 2.1.1)

> The available interfaces for each Debian release are defined in Debian
> Policy.

> [Rationale: this is how we have always done it: Policy explains the
> interfaces for package integration]

> (Option 2.1.2)

> The available interfaces for each Debian release are defined by the
> maintainers of the packages providing them.

> [Rationale: the maintainers of these packages have the best overview
> over which interfaces can be best supported for the support period of a
> release.]

We've always done a combination of these two things based on a lot of
factors: how foundational the interface is, how much time the relevant
teams have, etc.  I'm not sure it makes sense to collapse this waveform
quite this definitively.

> (Option 2.2.1)

> Core system components are excluded from backports, and backported
> packages need to be compatible with the interfaces provided by the
> stable release.

> [Rationale: it's a stable release.]

> (Option 2.2.2)

> It is permissible for backports to declare a dependency on a newer
> version of a core system component. Users installing a backported
> version of a service may be required to pull in backports of other
> packages.

> [Rationale: interfaces change, and it may not always be possible to
> combine two components from different releases]

This is an interesting question but I'm not sure it needs to be decided by
GR.  Is this really that controversial?  I'm not sure we've spent much

Re: [draft] Draft text on Init Systems GR

[Andrey Rahmatullin]

On Sat, Nov 09, 2019 at 06:08:54PM +0100, Simon Richter wrote:
> the main problem I see with this GR is that it is in essence a rehash of
> the GR[1] we had in 2014, with pretty much the same options minus the one
> that won, "A GR is not required."
The option that won is worded like this:

"""
The Debian project asks its members to be considerate when proposing General
Resolutions, as the GR process may be disruptive regardless of the outcome of
the vote.

Regarding the subject of this ballot, the Project affirms that the procedures
for decision making and conflict resolution are working adequately and thus
a General Resolution is not required.
"""

Are we still sure that the procedures are working adequately?


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: [draft] Draft text on Init Systems GR

[Simon Richter]

Hi,

the main problem I see with this GR is that it is in essence a rehash of
the GR[1] we had in 2014, with pretty much the same options minus the one
that won, "A GR is not required."

> Choice 1: Affirm Init Diversity

The way this is worded is even stronger than in the 2014 GR, which made
allowances for degraded operation, because it was already obvious then that
GNOME would tightly integrate with systemd.

We cannot sensibly pass this as a resolution because it would create tons
of highly complex RC bugs, something the 2014 GR proposal explicitly
avoided, so this would just set us up for another GR reversing the decision
in light of its total unworkability.

> Being able to run Debian systems with init systems other than systemd
> continues to be something that the project values.  With one
> exception, the Debian Project affirms the current policy on init
> scripts and starting daemons (policy 9.3.2, 9.11).

This is the smallest part of the problem. If it was about starting daemons,
we'd have found a solution already.

The question is what we do with packages that have an explicit functional
dependency on a particular feature only implemented in one particular
service orchestrator (because systemd is definitely more than a pure init
system, it just happens to include one as a byproduct).

The fact that only service start is documented in policy is a bug in
itself.

The question at this point is no longer "which init system do we want to
have", but "who sets policy for package integration?" -- and that is a
question that will have to be answered even in a systemd-only ecosystem.

So as a counterproposal, two major directions for diversity yes/no (with no
middle ground, and two further questions for each, then flattened out to
make use of the fact that we're using Condorcet and don't have to deal with
tactical voting.

(Common)

The Debian Project recognizes that several upstream software projects are
converging on a common service orchestrator architecture and therefore
require distribution maintainers to ensure that compatible interfaces are
provided when the software is installed. At the same time, users are
deploying Debian in environments where a hard dependency on a specific
service orchestrator either introduces additional complexity or conflicts
with other software.

[Rationale: we want to be the universal operating system, which includes
desktop, server, container and embedded setups, probably a few others, and
mixes between them. For desktop users, we need a default installation that
is fully functional, but container solutions have their own dependency
tracking across machines, and will make different decisions on which
services to deploy where than a standalone desktop system would make.]

(Option 1)

The Debian Project aims at providing the greatest configuration flexibility
while maintaining a sensible default installation for end users. To that
end, we document functional dependencies in a machine-readable way and
provide alternative variants if possible.

[Rationale: not every combination of software makes sense or has sufficient
interest to be maintained, and that is okay, but if there are users, we
should try to support them.]

(Option 1.1.1)

Automated variant transitions shall be supported.

[Rationale: moving from systemd to sysvinit is currently an involved manual
process, so unavailable to anyone not already skilled in Unix
administration, creating an artificial barrier.]

(Option 1.1.2)

Moving installations between variants shall be supported.

[Rationale: this is what we have now, so it probably should be an option]

(Option 1.1.3)

Installation variant is decided at installation time and there is no
expectation that this can be altered later.

[Rationale: this allows us to write package dependencies without regard for
conversion paths, and also gives administrators a scriptable path for
deployments, which they currently do not have.]

(Option 1.2.1)

Package maintainers for packages requiring tighter integration into a
particular ecosystem are asked to form teams to cover adequate integration
testing.

[Rationale: we're moving towards team maintenance in git anyway for many
packages. If someone volunteers to maintain a particular variant that they
also use, then that should probably work.]

(Option 1.2.2)

Package maintainers are asked to merge patches implementing support for
different ecosystems. Bug reports for problems arising on these variants
may be forwarded if they are packaging related.

[Rationale: this is like team maintenance, but with a hierarchy and lower
barrier to entry, in the hope that derived distributions send patches to
minimize differences]

(Option 1.2.3)

The same software may be packaged multiple times by different maintainers
if integration requirements cause incompatibilities.

[Rationale: this allows packaging to be kept simple, at the expense of some
space in the archive]

(Option 2)

The Debian project aims at providing a tightly integrated 

Re: [draft] Draft text on Init Systems GR

[Martin Pitt]

Hello Wouter,

Wouter Verhelst [2019-11-09 10:32 +0200]:
> > Choice 1: Affirm Init Diversity
> > 
> > Being able to run Debian systems with init systems other than systemd
> > continues to be something that the project values.  With one
> > exception, the Debian Project affirms the current policy on init
> > scripts and starting daemons (policy 9.3.2, 9.11).  Roughly, packages
> > should include init scripts to start services that are included.
> > Policy notes that early boot services like those started from
> > /etc/rcS.d may be tied closely to the init system in use.
> 
> I don't see why this is relevant in the current discussion.
> 
> My nbd-client package is one that is relevant here; it has a systemd
> unit, and an rcS init script (which is then ignored by systemd). If this
> choice wins, then init scripts remain mandatory. If you provide an rcS
> init script, then systemd units are also mandatory.

IMHO early-boot services in rcS.d are one of the most important aspects of this
entire discussion. Late boot services are generally easy, as the vast majority
have simple dependencies and simple startup logic in the sense of how deeply
they need to interact with the guts of the OS. Ignoring systemd features like
privilege reduction/isolation/robustness, a systemd unit and a SysV script that
uses /lib/init/init-d-script have roughly the same complexity. They are
reasonably easy to test on both a systemd and a SysV init system, and it's the
right thing to let them be maintained by the individual package maintainers.

But this picture is entirely different in early boot (rcS.d, or
sysinit.target): these have complex, brittle, and dynamic dependencies, are
hardware/install type/configuration dependent, and require an integrative
cross-package design, development, and maintenance.  This is the part where
SysV init scripts and distributed maintenance are desperately bad, and why a
lot of configurations had been so buggy or impossible for many years. They
suffer from imperative shell script hell and not enough machine
readability/introspectability/uniformity to reason about or validate them.

For these a distributed maintenance approach has been shown to not work well;
integrating NetworkManager, LUKS, NFS, LVM, RAID, dynamic partition type
detection, udev, X.org/wayland/login managers etc. needs to be a primary
responsibility of the team that maintains the init system itself [1].  These
need comprehensive system integration tests [2] with lots of different
scenarios.

This is the one thing in that GR that I have a strong opinion on (backed by
doing *two* init system migrations in my life): Choice 1 is a non-starter if it
mandates distributed SysV init script maintenance for early-boot services. If
these are exept, and maintained/QAed by the corresponding init system, then
Choice 1 is very sensible and practical.

I wish that the GR text could expand on that a little bit, but I do appreciate
that this quickly gets into the trenches of deep technical details. For now I
interpret the last sentence as a sufficient exception (avoiding the word
"loophole") for that scenario.

> So this is not an exception to the rule? It just means you have more
> work to do.

What do you mean by "more work to do"? I. e. what and who?

Thanks,

Martin

[1] That of course doesn't mean that the package maintainer doesn't have a say
in that -- they absolutely do. But to a large degree they need to trust and
defer to the maintainers of the init system.

[2] autopkgtests can also do that -- I wish we had had what we have today in
the upstart/early systemd times!

Re: [draft] Draft text on Init Systems GR

[Martin Pitt]

Hello all,

Sam Hartman [2019-11-07 13:04 -0500]:
> I hope my actions demonstrate that I've tried to work with and understand the
> needs of all sides here; that has been my intent.

Many thanks! (Again, in public now :-) )

Full disclosure: I discussed that with Sam in private before, as representative
of the systemd maintainers.

> Choice 1: Affirm Init Diversity
> 
> Being able to run Debian systems with init systems other than systemd
> continues to be something that the project values.  With one
> exception, the Debian Project affirms the current policy on init
> scripts and starting daemons (policy 9.3.2, 9.11).

To clarify: Is the exception to alter the "must" in the current policy, that
says

   However, any package integrating with other init systems must also be
   backwards-compatible with sysvinit by providing a SysV-style init script

?

> Roughly, packages should include init scripts to start services that are
> included.

I. e. changing "must" to "should", and thus stop making packages like
cockpit have an RC bug. cockpit has deep systemd dependencies both for startup
and at runtime -- support for non-systemd will not happen. So even choice 1
would mean to move from "everything in Debian must work with SysVinit" to "we
accept that there are some packages in the archive which only work with
systemd".

This may soon apply to GNOME as well:
https://blogs.gnome.org/benzea/2019/10/01/gnome-3-34-is-now-managed-using-systemd/

> Policy editors are requested to amend policy; including a service unit
> without an init script is appropriate for a non-maintainer upload but
> should no longer be an RC bug.

This is ambiguous: I think you mean that "a package having a service unit but
without an init script is no longer an RC bug", not that the process of
*including* a service unit is an RC bug. So how about

   a package having a service unit but without an init script is no longer an
   RC bug, but including an init script is appropriate for a non-maintainer
   upload.

?

> Policy editors are requested to consider whether there are cases where
> removing an init script that used to be provided should be RC because it
> would break a system on upgrade.

+1 that makes absolute sense for Choice 1.

Thanks,

Martin


signature.asc
Description: PGP signature

Re: [draft] Draft text on Init Systems GR

[Wouter Verhelst]

On Thu, Nov 07, 2019 at 01:04:20PM -0500, Sam Hartman wrote:
> 
> This is a draft GR.  I hope to be at a point where I could formally
> propose a GR in a week, assuming discussion converges that fast.

You can formally propose a GR today, and I recommend you do -- otherwise
we end up discussing things before the discussion period, and then you
need to sit and wait at least seven days during the *actual* discussion
period for no good reason.

Note that "proposing a GR" does not imply "calling for the vote"; that
happens later, after the GR has been properly drafted and discussion on
all amendments has ended.

Note also that every accepted amendment resets the discussion period,
and that while you have the ability (as DPL) to accept amendments
without seconds, and to vary the discussion period by up to a week, you
do not have the ability to eliminate the discussion period altogether.
Therefore it would make sense to have a formal GR proposal today so tha
amendments can be made.

> At this point, the question is whether the choices that need to be on
> the ballot are represented in this draft GR.
>
> I did not obtain a review of this version from someone who favors init
> diversity.

In my opinion, our GR procedure works best if every choice on the ballot
was drafted by someone who actually wants it to happen; otherwise you
run the risk of two problems:

- You may end up with options on the ballot that don't actually
  represent the opinion of *any* developer, *at all*. This represents
  clutter, and needlessly wastes time of voting developers who will have
  to wade through reading a (number of) useless options that nobody
  really wants.
- You will need to judge whether any proposed amendment matches the
  opinion of anyone who previously already agreed with that option, when
  you are not in the best position to do so. Every time you accept (or
  reject) an amendment, you run the risk of alienating whoever actually
  agreed with that proposal, possibly resulting in them proposing their
  own alternate option.

This almost ended up happening for GR 2004_004, and that one was a mess.

Given your above statement, I'm assuming that your preferred option is
#3. Is that correct?

> I didn't give them a lot of time, and they just wrote to let
> me know that they weren't going to be able to do a review this week.
> Based on the feedback from debian-devel I decided that getting text to
> the community now was the most important thing.
> If this text doesn't meet the needs of that community, we'll change the
> text.  I hope my actions demonstrate that I've tried to work with and
> understand the needs of all sides here; that has been my intent.
> 
> 
> 
> version 2330c05afa4
> 
> Using its power under Constitution section 4.1 (5), the project issues
> the following statement describing our current position on Init
> systems, Init system diversity, and the use of systemd features.  This
> statement describes the position of the project at the time it is
> adopted.  That position may evolve as time passes without the need to
> resort to future general resolutions.  The GR process remains
> available if the project needs a decision and cannot come to a
> consensus.
> 
> Choice 1: Affirm Init Diversity
> 
> Being able to run Debian systems with init systems other than systemd
> continues to be something that the project values.  With one
> exception, the Debian Project affirms the current policy on init
> scripts and starting daemons (policy 9.3.2, 9.11).  Roughly, packages
> should include init scripts to start services that are included.
> Policy notes that early boot services like those started from
> /etc/rcS.d may be tied closely to the init system in use.

I don't see why this is relevant in the current discussion.

My nbd-client package is one that is relevant here; it has a systemd
unit, and an rcS init script (which is then ignored by systemd). If this
choice wins, then init scripts remain mandatory. If you provide an rcS
init script, then systemd units are also mandatory.

So this is not an exception to the rule? It just means you have more
work to do.

> Init
> scripts are the lowest common denominator across all init systems.
> Packages may include support for init systems like systemd service
> units in addition to init scripts.  Current policy makes it an RC bug
> to include a service unit without an init script.
> 
> Policy editors are requested to amend policy; including a service unit
> without an init script is appropriate for a non-maintainer upload but
> should no longer be an RC bug.

If this choice wins, then why should it not be an RC bug to not have an
init script? That doesn't seem to make sense.

> Policy editors are requested to
> consider whether there are cases where removing an init script that
> used to be provided should be RC because it would break a system on
> upgrade.
> 
> Once the community of users of an alternate init system have said that
> 

Re: [draft] Draft text on Init Systems GR

[Sean Whitton]

Hello,

On Fri 08 Nov 2019 at 06:04PM +01, Ansgar wrote:

> No, but maybe I expressed myself badly: we have people that complain
> that building Debian source packages with a Debian-specific command is a
> too high burden.  This is independent of how source is represented (Git,
> .dsc, rpm, Git+LFS, only-debian/-Git+tar, references to external
> artifacts, ...).
>
> So some people believe that "Debian-specific tooling is bad", even for
> Debian-specific work.

Thanks for the clarification -- I see what you mean now.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: [draft] Draft text on Init Systems GR

[Ansgar]

Sean Whitton writes:
> On Fri 08 Nov 2019 at 04:51PM +01, Ansgar wrote:
>> We already have people complaining that source packages are "too Debian
>> specific" and should be replaced.  The tooling above is even more of a
>> problem as third parties currently have to deal with way too many
>> different ways to even before getting to packaging which is inherently
>> more package-manager- and thus distribution(-familiy)-specific.
>
> If you're referring to those of us who aren't keen on the .dsc transport
> format, I think that the point is orthogonal.  What we're talking about
> in this thread is the contents of binary packages.

No, but maybe I expressed myself badly: we have people that complain
that building Debian source packages with a Debian-specific command is a
too high burden.  This is independent of how source is represented (Git,
.dsc, rpm, Git+LFS, only-debian/-Git+tar, references to external
artifacts, ...).

So some people believe that "Debian-specific tooling is bad", even for
Debian-specific work.

> The reasons that there might be for reducing the amount of
> Debian-specific stuff in binary packages are quite different from the
> reasons for reducing the amount of Debian-specific stuff used in moving
> source code around.
>
> The basic reason for that is that what we are trying to produce is an
> operating system composed, roughly, of binary packages; we have produced
> ways to move source code around only incidentally to that.

Yes, and the software that gets packaged needs to interact with the rest
of an operating system in ways that upstream has to deal with.  They
benefit from common tooling across several distributions.  Additionally
it also reduces workload for people maintaining software in Debian.

In my opinion enabling the use of such tooling is quite useful and a
logical continuation of what already happened with, for example,
abstraction layers around session management for desktop environments.
Note that Debian already adopted these.

We also decreased use of Debian-specific tools such as the
Debian-specific menu system.

In some way this is "Debian-specific tooling is bad for tasks that are
not Debian-specific", that is a weaker version of the position above.
(This doesn't mean we shouldn't decrease Debian-specific tooling for
Debian-specific work if we can reasonably do so.)

Ansgar

Re: [draft] Draft text on Init Systems GR

[Sean Whitton]

Hello,

On Fri 08 Nov 2019 at 04:51PM +01, Ansgar wrote:

> We already have people complaining that source packages are "too Debian
> specific" and should be replaced.  The tooling above is even more of a
> problem as third parties currently have to deal with way too many
> different ways to even before getting to packaging which is inherently
> more package-manager- and thus distribution(-familiy)-specific.

If you're referring to those of us who aren't keen on the .dsc transport
format, I think that the point is orthogonal.  What we're talking about
in this thread is the contents of binary packages.

The reasons that there might be for reducing the amount of
Debian-specific stuff in binary packages are quite different from the
reasons for reducing the amount of Debian-specific stuff used in moving
source code around.

The basic reason for that is that what we are trying to produce is an
operating system composed, roughly, of binary packages; we have produced
ways to move source code around only incidentally to that.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: [draft] Draft text on Init Systems GR

[Ansgar]

Holger Levsen writes:
> On Thu, Nov 07, 2019 at 01:04:20PM -0500, Sam Hartman wrote:
>> 
>> version 2330c05afa4
[...]
>> Choice 3: systemd  without Diversity as a Priority
> [...]
>
> I guess this option will get ammendments:
>
> a.) 'systemd without diversity as a priority' sounds like systemd is
> against diversity. I think this is borderline insulting. So I expect
> this will attract someone proposing another option called 'Embrace
> the future (*) and a modern init system' or such.
> *) or 'Embrace new technologies...'
[...]
> On top of all of this, systemd provides much more features than unit
> files as the thread on -devel showed. There is no word about these
> technologies in this GR proposal. I think that's a flaw in this
> proposal.

Maybe something along the lines of "Embrace tooling diversity and
cross-distribution collaboration"?

This is about allowing experimenting with and possibly adopting new
tools (sysusers, tmpfiles, ...)  and making cross-distribution work
easier by standardizing "boring" aspects of packaging such as how to
create service accounts.

We already have people complaining that source packages are "too Debian
specific" and should be replaced.  The tooling above is even more of a
problem as third parties currently have to deal with way too many
different ways to even before getting to packaging which is inherently
more package-manager- and thus distribution(-familiy)-specific.

On the other side, we have Debian-specific, least common denominator
tooling that is hard to change.

Ansgar

Re: [draft] Draft text on Init Systems GR

[Holger Levsen]

On Thu, Nov 07, 2019 at 01:04:20PM -0500, Sam Hartman wrote:
> 
> version 2330c05afa4
 
> Choice 1: Affirm Init Diversity
[...]

looks generally like a fine option to me.

> Choice 2: systemd but we Support Exploring Alternatives
[...]

as others have said, this mixes init systems with systemd-logind.

> Choice 3: systemd  without Diversity as a Priority
[...]

I guess this option will get ammendments:

a.) 'systemd without diversity as a priority' sounds like systemd is
against diversity. I think this is borderline insulting. So I expect
this will attract someone proposing another option called 'Embrace
the future (*) and a modern init system' or such. 
*) or 'Embrace new technologies...'
b.) I guess some will want something like this option on the ballot but
without the commitment about working with downstreams _worded this
way_.
c.) Some will not want 'Packages should include service units or init
scripts to start daemons and services' but rather a much stronger
recommendation to drop init scripts and ship unit files.


On top of all of this, systemd provides much more features than unit
files as the thread on -devel showed. There is no word about these
technologies in this GR proposal. I think that's a flaw in this
proposal.

Then, I think the ballot also misses an option for the sysv-lovers,
'Embrace systems without systemd' or some such, which explicitly forbids
using systemd technology without alternative support working on sysv
systems. I think it would be very useful to know whether 0.5, 5%, or 15% or
25% (or more?) of our developers think such would be a good choice.

Finally, I don't think it's a good idea to rush this to a vote in 7
days. I'm tempted to mail d-d-a to make people who are not regularily
read -vote aware of this discussion. (There are also many people who
don't read -devel.)
Sam, I'd appreciate if I wouldn't need to do that, because you sent such
a short pointer to -vote on d-d-a *before* calling for a vote. Like now.

Last, and definitly not least: many thanks for working on this, Sam.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

why mention Constitution section 4.1 (5 or even 4)? (Re: [draft] Draft text on Init Systems GR)

[Holger Levsen]

On Thu, Nov 07, 2019 at 01:04:20PM -0500, Sam Hartman wrote:
> 
> version 2330c05afa4
> 
> Using its power under Constitution section 4.1 (5)

I fail to see why Constitution section 4.1 (5) is referred here. I'd
better understand section 4.1 (4) and would probably would prefer to
leave out this half sentence completly.

(I'll comment on other aspects seperately if I have more comments.)

Thanks.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Re: [draft] Draft text on Init Systems GR

[Ansgar]

Sam Hartman writes:
> At this point, the question is whether the choices that need to be on
> the ballot are represented in this draft GR.
[...]
> 
> version 2330c05afa4
[...]
> Choice 1: Affirm Init Diversity
>
> Being able to run Debian systems with init systems other than systemd
> continues to be something that the project values.  With one
> exception, the Debian Project affirms the current policy on init
> scripts and starting daemons (policy 9.3.2, 9.11).

I would not recommend referring to the "current policy" as it is unclear
what that is.  For example one of the Policy maintainers wrote:

+---
| The current Policy text is a mess, and everything it says on the topic is
| essentially accidental, being left over from text that was added to
| clarify how to support upstart, before the TC decision on the default init
| system.
+---[ https://lists.debian.org/msgid-search/87a79jjiug@hope.eyrie.org ]

That doesn't seem to be something that should be affirmed.

> Choice 2: systemd but we Support Exploring Alternatives
[...]
> Technologies such as elogind that facilitate exploring

systemd-shim and elogind?  It's not like elogind is the only fork of
systemd-logind ;-)

> Choice 3: systemd  without Diversity as a Priority
[...]
> Debian is committed to working with derivatives that make different
> choices about init systems.  As with all our interactions with
> downstreams, the relevant maintainers will work with the downstreams to
> figure out which changes it makes sense to fold into Debian and which
> changes remain purely in the derivative.

I don't think Debian should do such a specific commitment (also not in
Choice 2).  It's also a separate problem.

Ansgar

Re: [draft] Draft text on Init Systems GR

[Lucas Nussbaum]

On 07/11/19 at 13:59 -0500, Sam Hartman wrote:
> 
> Thanks for helping; resolving these sort of ambiguities are really
> appreciated.
> 
> > "Lucas" == Lucas Nussbaum  writes:
> 
> Lucas> Hi,
> Lucas> On 07/11/19 at 13:04 -0500, Sam Hartman wrote:
> >> Choice 2: systemd but we Support Exploring Alternatives
> >> Packages should include service units or init scripts to start
> >> daemons and services.  Packages may include support for alternate
> >> init systems besides systemd and may include alternatives for any
> >> systemd-specific interfaces they use.  Maintainers use their
> >> normal procedures for deciding which patches to include.
> 
> Lucas> I find this paragraph a bit hard to parse.
> 
> Lucas> "Packages should include service units or init scripts to
> Lucas> start daemons and services."
> 
> Lucas> My understanding is that we want packages to provide a way to
> Lucas> start daemons and services. Should this be read as:
> 
> Lucas>   Packages should include either service units or init
> Lucas> scripts to start daemons and services [= it works on
> Lucas> systemd].
> 
> That sentence does not express a preference between init scripts and
>  service units: as you point out both work on systemd.
> 
> So I think we read the same so far.
> 
> 
> Lucas> When including service units, packages should also
> Lucas> include init scripts [= the baseline solution].
> 
> Where do you get this?
> I find no textual support for this reading; it is certainly not my
> intent for choice 2 or 3
> 
> That is, under choice 2 and 3, it's intended to be acceptable to provide
> a service unit and nothing else.
> 
> 
> Lucas> Or is it expected that the "may" in this option stronger than
> Lucas> the "may" in the last option, because of the preceding
> Lucas> paragraph?
> 
> No, the difference intended between choice 2 and 3 is about how we
> handle technologies like elogind, or a mythical technology that parsed
> sysusers files, rather than how we handle starting daemons.

I must admit I haven't followed the elogind discussion (is there a
summary somewhere?). But how is is useful to support elogind if we say
"packages that include service units may also include init scripts",
thus making it OK for a system not to start services at boot if another
init system is in use?

What I'm concerned about is that the proposed GR is conflating two
different questions that are not completely orthogonal, but quite
orthogonal:
- whether init scripts must/should/may be included when there's already
  a service unit
- whether exploring elogind support should be supported by Debian
Maybe it might be better to unfold the possible combinations that make
sense in the list of options.

Lucas

Re: [draft] Draft text on Init Systems GR

[Russ Allbery]

Sam Hartman  writes:

> That sentence does not express a preference between init scripts and
> service units: as you point out both work on systemd.

> So I think we read the same so far.

Note that we're currently discussing whether Policy will recommend
(should) that any package with a service ship a systemd service unit,
since the quality of implementation experience for systemd is generally
better.  (The systemd unit generator that supports init scripts has to
make various compromises that leads to inferior results compared to native
units.)

I don't think this matters a ton for the text, but the choice on the
Policy side (at least at the recommendation level) is likely to look more
like "include both a systemd unit and an init script" (option 1) or
"include a systemd unit, and an init script if you want" (option 3).
Including only an init script results is a worse experience for the
default init system and therefore is likely to be deprecated (although not
forbidden).

See https://bugs.debian.org/941198 for more discussion.

-- 
Russ Allbery (r...@debian.org)  

Re: [draft] Draft text on Init Systems GR

[Lucas Nussbaum]

Hi,

On 07/11/19 at 13:04 -0500, Sam Hartman wrote:
> Choice 2: systemd but we Support Exploring Alternatives
> 
> 
> The Debian project recognizes that systemd service units are the
> preferred configuration for describing how to start a daemon/service.
> However, Debian remains an environment where developers and users can
> explore and develop alternate init systems and alternatives to systemd
> features.  Those interested in exploring such alternatives need to
> provide the necessary development and packaging resources to do that
> work.  Technologies such as elogind that facilitate exploring
> alternatives while running software that depends on some systemd
> interfaces remain important to Debian.  It is important that the
> project support the efforts of developers working on such technologies
> where there is overlap between these technologies and the rest of the
> project, for example by reviewing patches and participating in
> discussions in a timely manner.
> 
> 
> Packages should include service units or init scripts to start daemons
>   and services.  Packages may include support for alternate init
>   systems besides systemd and may include alternatives for any
>   systemd-specific interfaces they use.  Maintainers use their normal
>   procedures for deciding which patches to include.

I find this paragraph a bit hard to parse.

"Packages should include service units or init scripts to start
daemons and services."

My understanding is that we want packages to provide a way to start
daemons and services. Should this be read as:

  Packages should include either service units or init scripts to start
  daemons and services [= it works on systemd]. When including service
  units, packages should also include init scripts [= the baseline
  solution].

Or is it expected that the "may" in this option stronger than the "may"
in the last option, because of the preceding paragraph?

Lucas

Re: [draft] Draft text on Init Systems GR

[Sam Hartman]

Thanks for helping; resolving these sort of ambiguities are really
appreciated.

> "Lucas" == Lucas Nussbaum  writes:

Lucas> Hi,
Lucas> On 07/11/19 at 13:04 -0500, Sam Hartman wrote:
>> Choice 2: systemd but we Support Exploring Alternatives
>> Packages should include service units or init scripts to start
>> daemons and services.  Packages may include support for alternate
>> init systems besides systemd and may include alternatives for any
>> systemd-specific interfaces they use.  Maintainers use their
>> normal procedures for deciding which patches to include.

Lucas> I find this paragraph a bit hard to parse.

Lucas> "Packages should include service units or init scripts to
Lucas> start daemons and services."

Lucas> My understanding is that we want packages to provide a way to
Lucas> start daemons and services. Should this be read as:

Lucas>   Packages should include either service units or init
Lucas> scripts to start daemons and services [= it works on
Lucas> systemd].

That sentence does not express a preference between init scripts and
 service units: as you point out both work on systemd.

So I think we read the same so far.


Lucas> When including service units, packages should also
Lucas> include init scripts [= the baseline solution].

Where do you get this?
I find no textual support for this reading; it is certainly not my
intent for choice 2 or 3

That is, under choice 2 and 3, it's intended to be acceptable to provide
a service unit and nothing else.


Lucas> Or is it expected that the "may" in this option stronger than
Lucas> the "may" in the last option, because of the preceding
Lucas> paragraph?

No, the difference intended between choice 2 and 3 is about how we
handle technologies like elogind, or a mythical technology that parsed
sysusers files, rather than how we handle starting daemons.