Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1167482 > unrolled thread

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services Russ Allbery <rra@debian.org> - 2023-09-10 04:00 +0200
    Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services Russ Allbery <rra@debian.org> - 2023-09-10 04:30 +0200
      Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services Luca Boccassi <bluca@debian.org> - 2023-09-10 12:30 +0200
        Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services Sam Hartman <hartmans@debian.org> - 2023-09-11 01:20 +0200
          Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services Russ Allbery <rra@debian.org> - 2023-09-12 06:20 +0200
            Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services Luca Boccassi <bluca@debian.org> - 2023-09-12 08:20 +0200
    Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services Edward Little <e.little598@gmail.com> - 2023-09-11 03:10 +0200

#1167482 — Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Multipart message — attachments visible in raw view] — view raw

Luca Boccassi <bluca@debian.org> writes:

> systemd upstream will drop support for the transitional sysv generator
> in the near future. The transition is long finished, it's been at least
> a decade, and it's time for the tail of packages still shipping only
> init scripts but not units to be updated.

> Tentatively this should happen within Trixie's development cycle. Of
> course it's free software and generators are not that difficult to
> maintain, so if someone wanted to lift the sysv generator out of the
> systemd repository and adapt it to be a standalone binary there's
> nothing stopping them. But I wouldn't want the systemd package to depend
> on such a backward compat tool, so packages needing this hyptothetical
> package should depend explicitly on it. This is just mentioned for
> completeness, it's been at least a decade and writing a unit file is
> beyond trivial so there shouldn't be any issue adding the few remaining
> ones.

The mass bug filing happened, and although there were some objections on
debian-devel, I don't think any of them were blocking.  Specifically, I
did not see anyone present a concrete plan for how to keep the systemd
unit generator or some equivalent alive, and given that systemd upstream
is dropping support for this feature, I believe that's the only way for
this change to not be effective mandatory.

Therefore, I think the time is ripe to proceed with this Policy change.

I took a detailed look at this part of Policy today, and the whole system
service section needs serious work.  I believe the instructions it
currently provides for constructing package maintainer scripts won't
actually work with a current Debian system, and most Debian packages are
technically violating the current Policy because it hasn't been updated
for how systemd units work today.  I started on overhauling that section,
but it became clear that this is going to be a larger project with some
potentially controversial decisions, so I'm going to open a new bug about
that so that we don't block this change on that work.

I made the following changes to your last diff:

* Move the "should" about integrating with service management to the
  parent section.

* Explicitly say that systemd is the default init system and service
  manager (it feels like we should say this somewhere, and I don't think
  we already do).

* Add an explicit exception for packages intended only to support
  alternate init systems.  (As an obvious example, sysvinit isn't going to
  ship a systemd unit, nor should it.)

* Delete the paragraph suggesting that packages without systemd units
  should write an init script, since this will no longer accomplish the
  goal of getting that system service to work with systemd and therefore
  no longer seems to serve a purpose.

Here is what I came up with.  I think it is ready for seconds or
objections.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [next] | [standalone]

#1167484

Russ Allbery <rra@debian.org> writes:

> -If a service unit is not present, ``systemd`` uses dependency information
> -contained within the init scripts and symlinks in ``/etc/rcn.d`` to decide
> -which scripts to run and in which order.  The ``sysv-rc`` runlevel system
> -for ``sysvinit`` uses the same symlinks in ``/etc/rcn.d`` to decide which
> -scripts to run and in which order at boot time and when the init state (or
> -"runlevel") is changed.  See the ``README.runlevels`` file shipped with
> -``sysv-rc`` for implementation details.  Other alternatives might exist.
> +``systemd`` uses dependency and ordering information contained within the
> ++enabled unit files to decide which services to run and in which order.
> +The ``sysv-rc`` runlevel system for ``sysvinit`` uses the same symlinks in
> +``/etc/rcn.d`` to decide which scripts to run and in which order at boot
> +time and when the init state (or "runlevel") is changed.  See the
> +``README.runlevels`` file shipped with ``sysv-rc`` for implementation
> +details.  Other alternatives might exist.

And of course I have to post the diff to see the bugs.  The part that says
"uses the same symlinks" should now say "uses symlinks".

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#1167519

On Sun, 10 Sept 2023 at 03:19, Russ Allbery <rra@debian.org> wrote:
>
> Russ Allbery <rra@debian.org> writes:
>
> > -If a service unit is not present, ``systemd`` uses dependency information
> > -contained within the init scripts and symlinks in ``/etc/rcn.d`` to decide
> > -which scripts to run and in which order.  The ``sysv-rc`` runlevel system
> > -for ``sysvinit`` uses the same symlinks in ``/etc/rcn.d`` to decide which
> > -scripts to run and in which order at boot time and when the init state (or
> > -"runlevel") is changed.  See the ``README.runlevels`` file shipped with
> > -``sysv-rc`` for implementation details.  Other alternatives might exist.
> > +``systemd`` uses dependency and ordering information contained within the
> > ++enabled unit files to decide which services to run and in which order.
> > +The ``sysv-rc`` runlevel system for ``sysvinit`` uses the same symlinks in
> > +``/etc/rcn.d`` to decide which scripts to run and in which order at boot
> > +time and when the init state (or "runlevel") is changed.  See the
> > +``README.runlevels`` file shipped with ``sysv-rc`` for implementation
> > +details.  Other alternatives might exist.
>
> And of course I have to post the diff to see the bugs.  The part that says
> "uses the same symlinks" should now say "uses symlinks".

Thank you, looks good to me, seconded.

[toc] | [prev] | [next] | [standalone]

#1167645

[Multipart message — attachments visible in raw view] — view raw

>>>>> "Luca" == Luca Boccassi <bluca@debian.org> writes:

    Luca> On Sun, 10 Sept 2023 at 03:19, Russ Allbery <rra@debian.org> wrote:
    >> 
    >> Russ Allbery <rra@debian.org> writes:
    >> 
    >> > -If a service unit is not present, ``systemd`` uses dependency
    >> information > -contained within the init scripts and symlinks in
    >> ``/etc/rcn.d`` to decide > -which scripts to run and in which
    >> order.  The ``sysv-rc`` runlevel system > -for ``sysvinit`` uses
    >> the same symlinks in ``/etc/rcn.d`` to decide which > -scripts to
    >> run and in which order at boot time and when the init state (or >
    >> -"runlevel") is changed.  See the ``README.runlevels`` file
    >> shipped with > -``sysv-rc`` for implementation details.  Other
    >> alternatives might exist.  > +``systemd`` uses dependency and
    >> ordering information contained within the > ++enabled unit files
    >> to decide which services to run and in which order.  > +The
    >> ``sysv-rc`` runlevel system for ``sysvinit`` uses the same
    >> symlinks in > +``/etc/rcn.d`` to decide which scripts to run and
    >> in which order at boot > +time and when the init state (or
    >> "runlevel") is changed.  See the > +``README.runlevels`` file
    >> shipped with ``sysv-rc`` for implementation > +details.  Other
    >> alternatives might exist.
    >> 
    >> And of course I have to post the diff to see the bugs.  The part
    >> that says "uses the same symlinks" should now say "uses
    >> symlinks".

    Luca> Thank you, looks good to me, seconded.

LGTM too, seconded.

[toc] | [prev] | [next] | [standalone]

#1167860

Sam Hartman <hartmans@debian.org> writes:
>>>>>> "Luca" == Luca Boccassi <bluca@debian.org> writes:

>     Luca> Thank you, looks good to me, seconded.

> LGTM too, seconded.

Thanks!  This has now been merged for the next Policy release.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#1167869

[Multipart message — attachments visible in raw view] — view raw

On Tue, 12 Sep 2023, 06:13 Russ Allbery, <rra@debian.org> wrote:

> Sam Hartman <hartmans@debian.org> writes:
> >>>>>> "Luca" == Luca Boccassi <bluca@debian.org> writes:
>
> >     Luca> Thank you, looks good to me, seconded.
>
> > LGTM too, seconded.
>
> Thanks!  This has now been merged for the next Policy release.
>

That's great, thank you!

>

[toc] | [prev] | [next] | [standalone]

#1167656

[Multipart message — attachments visible in raw view] — view raw

Please remove the following email address:  e.little598@gmail.com

On Sat, Sep 9, 2023 at 10:15 PM Russ Allbery <rra@debian.org> wrote:

> Luca Boccassi <bluca@debian.org> writes:
>
> > systemd upstream will drop support for the transitional sysv generator
> > in the near future. The transition is long finished, it's been at least
> > a decade, and it's time for the tail of packages still shipping only
> > init scripts but not units to be updated.
>
> > Tentatively this should happen within Trixie's development cycle. Of
> > course it's free software and generators are not that difficult to
> > maintain, so if someone wanted to lift the sysv generator out of the
> > systemd repository and adapt it to be a standalone binary there's
> > nothing stopping them. But I wouldn't want the systemd package to depend
> > on such a backward compat tool, so packages needing this hyptothetical
> > package should depend explicitly on it. This is just mentioned for
> > completeness, it's been at least a decade and writing a unit file is
> > beyond trivial so there shouldn't be any issue adding the few remaining
> > ones.
>
> The mass bug filing happened, and although there were some objections on
> debian-devel, I don't think any of them were blocking.  Specifically, I
> did not see anyone present a concrete plan for how to keep the systemd
> unit generator or some equivalent alive, and given that systemd upstream
> is dropping support for this feature, I believe that's the only way for
> this change to not be effective mandatory.
>
> Therefore, I think the time is ripe to proceed with this Policy change.
>
> I took a detailed look at this part of Policy today, and the whole system
> service section needs serious work.  I believe the instructions it
> currently provides for constructing package maintainer scripts won't
> actually work with a current Debian system, and most Debian packages are
> technically violating the current Policy because it hasn't been updated
> for how systemd units work today.  I started on overhauling that section,
> but it became clear that this is going to be a larger project with some
> potentially controversial decisions, so I'm going to open a new bug about
> that so that we don't block this change on that work.
>
> I made the following changes to your last diff:
>
> * Move the "should" about integrating with service management to the
>   parent section.
>
> * Explicitly say that systemd is the default init system and service
>   manager (it feels like we should say this somewhere, and I don't think
>   we already do).
>
> * Add an explicit exception for packages intended only to support
>   alternate init systems.  (As an obvious example, sysvinit isn't going to
>   ship a systemd unit, nor should it.)
>
> * Delete the paragraph suggesting that packages without systemd units
>   should write an init script, since this will no longer accomplish the
>   goal of getting that system service to work with systemd and therefore
>   no longer seems to serve a purpose.
>
> Here is what I came up with.  I think it is ready for seconds or
> objections.
>
> --
> Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>
>
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web