Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1039142: busybox: ships sysv-init script without systemd unit
19 views
Skip to first unread message
Michael Tokarev
Nov 13, 2023, 10:50:06 AM11/13/23
to
Control: tag -1 + help
On Sun, 25 Jun 2023 23:20:24 +0100 bl...@debian.org wrote:
> Package: busybox
> Severity: important
> User: bl...@debian.org
> Usertags: missing-systemd-service
>
> Dear Maintainer(s),
>
> busybox has been flagged by Lintian as shipping a sysv-init script
> without a corresponding systemd unit file. The default init system in
> Debian is systemd, and so far this worked because a transitional
> sysv-init-to-unit generator was shipped by systemd. This is in the
> process of being deprecated and will be removed by the time Trixie
> ships, so the remaining packages that ship init scripts without
> systemd units will stop working.
>
> There are various advantages to using native units, for example the
> legacy generator cannot tell the different between a oneshot service
> and a long running daemon. Also, sanboxing and security features
> become available for services. For more information, consult the
> systemd documentation:
> https://www.freedesktop.org/software/systemd/man/systemd.unit.html
>
> You can find the Lintian warning here:
>
> https://lintian.debian.org/sources/busybox
This site can't be found. But it's ok.
So in current state, only udhcpd lacks systemd file. So I tried to
provide one. The initscript for udhcpd checks for UDHCPD_ENABLED=yes/no
in /etc/default/udhcpd and does nothing if it is not enabled, which
is the default. Since there's no way in systemd to check for that
(well, there is, with ExecConditional, but it ugly at best), I thought
to ship udhcpd.service not enabled by default. Except it doesn't
work.
With just dh_installsystemd --no-enable, it is still started.
With dh_installsystemd --no-enable --no-start, it is started
as well, - apparently because initscript is started. Also,
with --no-enable --no-start, it is not restarted on upgrades
if enabled locally.
After doing several iterations, I decided to abandon this attempt, -
it just does not work, and I've no time to fight with the tools.
If someone has a working recipe for all this madness, please
share a patch for d/rules.
Tagging with "help" for now.
Thanks,
/mjt
On Sun, 25 Jun 2023 23:20:24 +0100 bl...@debian.org wrote:
> Package: busybox
> Severity: important
> User: bl...@debian.org
> Usertags: missing-systemd-service
>
> Dear Maintainer(s),
>
> busybox has been flagged by Lintian as shipping a sysv-init script
> without a corresponding systemd unit file. The default init system in
> Debian is systemd, and so far this worked because a transitional
> sysv-init-to-unit generator was shipped by systemd. This is in the
> process of being deprecated and will be removed by the time Trixie
> ships, so the remaining packages that ship init scripts without
> systemd units will stop working.
>
> There are various advantages to using native units, for example the
> legacy generator cannot tell the different between a oneshot service
> and a long running daemon. Also, sanboxing and security features
> become available for services. For more information, consult the
> systemd documentation:
> https://www.freedesktop.org/software/systemd/man/systemd.unit.html
>
> You can find the Lintian warning here:
>
> https://lintian.debian.org/sources/busybox
This site can't be found. But it's ok.
So in current state, only udhcpd lacks systemd file. So I tried to
provide one. The initscript for udhcpd checks for UDHCPD_ENABLED=yes/no
in /etc/default/udhcpd and does nothing if it is not enabled, which
is the default. Since there's no way in systemd to check for that
(well, there is, with ExecConditional, but it ugly at best), I thought
to ship udhcpd.service not enabled by default. Except it doesn't
work.
With just dh_installsystemd --no-enable, it is still started.
With dh_installsystemd --no-enable --no-start, it is started
as well, - apparently because initscript is started. Also,
with --no-enable --no-start, it is not restarted on upgrades
if enabled locally.
After doing several iterations, I decided to abandon this attempt, -
it just does not work, and I've no time to fight with the tools.
If someone has a working recipe for all this madness, please
share a patch for d/rules.
Tagging with "help" for now.
Thanks,
/mjt
Luca Boccassi
Nov 14, 2023, 7:23:00 AM11/14/23
to
On Mon, 13 Nov 2023 18:42:09 +0300 Michael Tokarev <m...@tls.msk.ru>
wrote:
Yeah things around Lintian publishing have changed since these bugs
have been filed
> So in current state, only udhcpd lacks systemd file. So I tried to
> provide one. The initscript for udhcpd checks for
UDHCPD_ENABLED=yes/no
> in /etc/default/udhcpd and does nothing if it is not enabled, which
> is the default. Since there's no way in systemd to check for that
> (well, there is, with ExecConditional, but it ugly at best), I
thought
> to ship udhcpd.service not enabled by default. Except it doesn't
> work.
>
> With just dh_installsystemd --no-enable, it is still started.
> With dh_installsystemd --no-enable --no-start, it is started
> as well, - apparently because initscript is started. Also,
> with --no-enable --no-start, it is not restarted on upgrades
> if enabled locally.
>
> After doing several iterations, I decided to abandon this attempt, -
> it just does not work, and I've no time to fight with the tools.
>
> If someone has a working recipe for all this madness, please
> share a patch for d/rules.
>
> Tagging with "help" for now.
Could you please share a branch or a patch with your attempt? What you
tried should work, but it's hard to say without looking at the
implementation in details.
--
Kind regards,
Luca Boccassi
wrote:
have been filed
> So in current state, only udhcpd lacks systemd file. So I tried to
> provide one. The initscript for udhcpd checks for
UDHCPD_ENABLED=yes/no
> in /etc/default/udhcpd and does nothing if it is not enabled, which
> is the default. Since there's no way in systemd to check for that
> (well, there is, with ExecConditional, but it ugly at best), I
thought
> to ship udhcpd.service not enabled by default. Except it doesn't
> work.
>
> With just dh_installsystemd --no-enable, it is still started.
> With dh_installsystemd --no-enable --no-start, it is started
> as well, - apparently because initscript is started. Also,
> with --no-enable --no-start, it is not restarted on upgrades
> if enabled locally.
>
> After doing several iterations, I decided to abandon this attempt, -
> it just does not work, and I've no time to fight with the tools.
>
> If someone has a working recipe for all this madness, please
> share a patch for d/rules.
>
> Tagging with "help" for now.
tried should work, but it's hard to say without looking at the
implementation in details.
--
Kind regards,
Luca Boccassi
Michael Tokarev
Nov 14, 2023, 9:50:05 AM11/14/23
to
14.11.2023 14:56, Luca Boccassi wrote:
> On Mon, 13 Nov 2023 18:42:09 +0300 Michael Tokarev <m...@tls.msk.ru>
> wrote:
..
> On Mon, 13 Nov 2023 18:42:09 +0300 Michael Tokarev <m...@tls.msk.ru>
> wrote:
>> With just dh_installsystemd --no-enable, it is still started.
>> With dh_installsystemd --no-enable --no-start, it is started
>> as well, - apparently because initscript is started. Also,
>> with --no-enable --no-start, it is not restarted on upgrades
>> if enabled locally.
>>
>> After doing several iterations, I decided to abandon this attempt, -
>> it just does not work, and I've no time to fight with the tools.
>>
>> If someone has a working recipe for all this madness, please
>> share a patch for d/rules.
>>
>> Tagging with "help" for now.
>
> Could you please share a branch or a patch with your attempt? What you
> tried should work, but it's hard to say without looking at the
> implementation in details.
https://salsa.debian.org/installer-team/busybox/-/blob/master/debian/rules#L172
with udhcpd.service & udhcpd.init in the same dir.
Thanks,
/mjt
0 new messages