Re: MBF: packages shipping init scripts without corresponding systemd units

2023-06-26 Thread Scott Kitterman
On Monday, June 26, 2023 11:52:05 AM EDT Wouter Verhelst wrote:
> On Sun, Jun 25, 2023 at 10:31:35PM +0100, Luca Boccassi wrote:
> > On Sun, 25 Jun 2023 at 22:29, Luca Boccassi  wrote:
> > > Hi,
> > > 
> > > According to Lintian there are 314 packages shipping init scripts
> > > without a corresponding systemd unit:
> > > 
> > > https://lintian.debian.org/tags/missing-systemd-service-for-init.d-scrip
> > > t
> > > 
> > > They currently work because there is still a transitional unit
> > > generator that creates a unit on-the-fly on boot. This was always
> > > intended as a temporary stop-gap, and is technically vastly inferior to
> > > a native unit, as for example it cannot tell the difference between a
> > > one-shot and a long-running service, and cannot enable any hardening or
> > > sandboxing options.
> > > 
> > > Now the generator is also on the way to be deprecated and removed. It's
> > > been there for a decade, which is enough time to complete the
> > > transition, and will likely be removed before Trixie ships.
> > > 
> > > Therefore I filed a bug against all affected packages, provided a patch
> > > for policy:
> > > 
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039102
> > > 
> > > and a patch for Lintian to bump the severity from warning to error:
> > > 
> > > https://salsa.debian.org/lintian/lintian/-/merge_requests/407
> > > 
> > > It's possible that there will be a good chunk of false positives, as
> > > often new units added don't have a name that matches exactly the old
> > > init script name, in which case it's fine to add an override and close
> > > the bug.
> > 
> > It would probably make things easier if I typed the destination
> > address correctly.
> 
> It's generally expected that you discuss MBFs on this list *before*
> actually performing the MBF, so that other options can be discussed, but
> meh, whatever.

And also so someone can point out your list of affected packages contains 
packages that only exist in oldstable so you can revise you list before 
submitting the bugs.

Scott K


signature.asc
Description: This is a digitally signed message part.


Re: MBF: packages shipping init scripts without corresponding systemd units

2023-06-26 Thread Wouter Verhelst
On Sun, Jun 25, 2023 at 10:31:35PM +0100, Luca Boccassi wrote:
> On Sun, 25 Jun 2023 at 22:29, Luca Boccassi  wrote:
> >
> > Hi,
> >
> > According to Lintian there are 314 packages shipping init scripts
> > without a corresponding systemd unit:
> >
> > https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script
> >
> > They currently work because there is still a transitional unit
> > generator that creates a unit on-the-fly on boot. This was always
> > intended as a temporary stop-gap, and is technically vastly inferior to
> > a native unit, as for example it cannot tell the difference between a
> > one-shot and a long-running service, and cannot enable any hardening or
> > sandboxing options.
> >
> > Now the generator is also on the way to be deprecated and removed. It's
> > been there for a decade, which is enough time to complete the
> > transition, and will likely be removed before Trixie ships.
> >
> > Therefore I filed a bug against all affected packages, provided a patch
> > for policy:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039102
> >
> > and a patch for Lintian to bump the severity from warning to error:
> >
> > https://salsa.debian.org/lintian/lintian/-/merge_requests/407
> >
> > It's possible that there will be a good chunk of false positives, as
> > often new units added don't have a name that matches exactly the old
> > init script name, in which case it's fine to add an override and close
> > the bug.
> 
> It would probably make things easier if I typed the destination
> address correctly.

It's generally expected that you discuss MBFs on this list *before*
actually performing the MBF, so that other options can be discussed, but
meh, whatever.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.



Re: MBF: packages shipping init scripts without corresponding systemd units

2023-06-26 Thread Luca Boccassi
On Mon, 26 Jun 2023 at 05:21, Paul Wise  wrote:
>
> On Sun, 2023-06-25 at 22:31 +0100, Luca Boccassi wrote:
>
> > Now the generator is also on the way to be deprecated and removed.
> ...
> > Therefore I filed a bug against all affected packages ...
>
> Will the generator be available separately for people who have packages
> not in Debian that still only have init scripts, or for people who have
> local init scripts installed manually or with config management tools?

It will not, it's going to be removed upstream and hence from
src:systemd. Exact date/version is not planned yet, but it will be
before Trixie's dev cycle ends. It will be written down in the release
notes when the time comes.

Kind regards,
LUca Boccassi



Re: MBF: packages shipping init scripts without corresponding systemd units

2023-06-25 Thread Paul Wise
On Sun, 2023-06-25 at 22:31 +0100, Luca Boccassi wrote:

> Now the generator is also on the way to be deprecated and removed.
...
> Therefore I filed a bug against all affected packages ...

Will the generator be available separately for people who have packages
not in Debian that still only have init scripts, or for people who have
local init scripts installed manually or with config management tools?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part


Re: MBF: packages shipping init scripts without corresponding systemd units

2023-06-25 Thread Luca Boccassi
On Sun, 25 Jun 2023 at 22:29, Luca Boccassi  wrote:
>
> Hi,
>
> According to Lintian there are 314 packages shipping init scripts
> without a corresponding systemd unit:
>
> https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script
>
> They currently work because there is still a transitional unit
> generator that creates a unit on-the-fly on boot. This was always
> intended as a temporary stop-gap, and is technically vastly inferior to
> a native unit, as for example it cannot tell the difference between a
> one-shot and a long-running service, and cannot enable any hardening or
> sandboxing options.
>
> Now the generator is also on the way to be deprecated and removed. It's
> been there for a decade, which is enough time to complete the
> transition, and will likely be removed before Trixie ships.
>
> Therefore I filed a bug against all affected packages, provided a patch
> for policy:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039102
>
> and a patch for Lintian to bump the severity from warning to error:
>
> https://salsa.debian.org/lintian/lintian/-/merge_requests/407
>
> It's possible that there will be a good chunk of false positives, as
> often new units added don't have a name that matches exactly the old
> init script name, in which case it's fine to add an override and close
> the bug.

It would probably make things easier if I typed the destination
address correctly.