Hi!

Lintian just started erroring on 'depends-on-obsolete-package
lsb-base' on many of my packages yesterday. There are no new uploads
of lsb-base recently and I did not find any news about this topic. The
Lintian page https://lintian.debian.org/tags/depends-on-obsolete-package
is only about the error in general, not any mention of lsb-base
specific changes.

Does somebody know what is going on?

Example:
E: mariadb-server: depends-on-obsolete-package Depends: lsb-base (>= 3.0-10)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-01-18 Otto Kek�l�inen <otto@kekalainen.net> wrote:

Lintian just started erroring on 'depends-on-obsolete-package
lsb-base' on many of my packages yesterday. There are no new uploads

[...]

Does somebody know what is going on?

Example:
E: mariadb-server: depends-on-obsolete-package Depends: lsb-base (>= 3.0-10)

That is this change
* Remove init.d-script-needs-depends-on-lsb-base and add lsb-base to
obsolete-packages. (Closes: #1019851)

from this commit:

commit 97f742b00553a4dd7ba681aefa4cc164ea263f71
Remove init.d-script-needs-depends-on-lsb-base and add lsb-base to obsolete-packages

The functionality of lsb-base is in the Essential:yes set since
Bullseye. The package itself is now an empty transitional package
(because debootstrap doesn't understand the Provides relationship) which
depends on the new provider of the functionality, sysvinit-utils, which
is also in the Essential:yes set.

Closes: #1019851

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Jan 18, 2023 at 08:19:15AM -0800, Otto Kekäläinen wrote:

Lintian just started erroring on 'depends-on-obsolete-package
lsb-base' on many of my packages yesterday.

It's a very low priority cleanup; the Depends is redundant but
harmless.

There are no new uploads of lsb-base recently

Relevant changes are from September. The lsb-base package is empty,
and would have been gone completely if debootstrap understood Provides.

and I did not find any news about this topic. The
Lintian page https://lintian.debian.org/tags/depends-on-obsolete-package
is only about the error in general, not any mention of lsb-base
specific changes.

The description of "$PACKAGE1 => $PACKAGE2" are clear enough, of
"$PACKAGE => nothing" a bit less, indeed. You can just drop the dependency.

Does somebody know what is going on?

Example:
E: mariadb-server: depends-on-obsolete-package Depends: lsb-base (>= 3.0-10)

The severity of this warning is grossly overstated. It shouldn't be an
"error" but a "mild warning to fix if you're bored".


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine. ⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄⠀⠀⠀⠀

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Adam Borowski <kilobyte@angband.pl> writes:

On Wed, Jan 18, 2023 at 08:19:15AM -0800, Otto Kekäläinen wrote:

Does somebody know what is going on?

Example:
E: mariadb-server: depends-on-obsolete-package Depends: lsb-base (>= 3.0-10)

The severity of this warning is grossly overstated. It shouldn't be an "error" but a "mild warning to fix if you're bored".

Unfortunately, Lintian doesn't support different severities for different iterations of the same tag. We currently have to pick one severity for
all depends-on-obsolete-package tags. Sometimes it's more important
(because we're trying to retire a package for the next release); other
times, it's not, such as here.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 2023-01-18 at 18:23:16 +0100, Adam Borowski wrote:

On Wed, Jan 18, 2023 at 08:19:15AM -0800, Otto Kekäläinen wrote:

Lintian just started erroring on 'depends-on-obsolete-package
lsb-base' on many of my packages yesterday.

It's a very low priority cleanup; the Depends is redundant but
harmless.

I don't think it is redundant though? Just removing the lsb-base
Depends can break packages on partial upgrades in the same way lsb-base
broke stuff before it grew a versioned dependency on sysvinit-utils.

While lsb-base is Priority required in bullseye, it is optional in
bookworm (although I think at least for apt these might be sticky?),
but regardless, if there are no remaining dependencies on it, these
could end up being removed by eager users.

There are no new uploads of lsb-base recently

Relevant changes are from September. The lsb-base package is empty,
and would have been gone completely if debootstrap understood Provides.

That would have also broken partial upgrades iff packages then removed
the dependency.

and I did not find any news about this topic. The
Lintian page https://lintian.debian.org/tags/depends-on-obsolete-package
is only about the error in general, not any mention of lsb-base
specific changes.

The description of "$PACKAGE1 => $PACKAGE2" are clear enough, of
"$PACKAGE => nothing" a bit less, indeed. You can just drop the dependency.

Does somebody know what is going on?

Example:
E: mariadb-server: depends-on-obsolete-package Depends: lsb-base (>= 3.0-10)

The severity of this warning is grossly overstated. It shouldn't be an "error" but a "mild warning to fix if you're bored".

I think the lintian tag should either tell to replace lsb-base with «sysvinit-utils (>= 3.05-4~)» or it should say nothing and packages
should simply live with that dependency until the next release, then
it can be dropped. The advantage of the second option is that it
implies less packaging churn.

Regards,
Guillem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 20 Jan 2023 at 12:15:31 +0100, Guillem Jover wrote:

I don't think it is redundant though? Just removing the lsb-base
Depends can break packages on partial upgrades in the same way lsb-base
broke stuff before it grew a versioned dependency on sysvinit-utils.

Yes, ish.

The vast majority of dependencies on lsb-base are going to be for LSB init scripts, which are normally run by either systemd-sysv-generator(8), or sysv-rc, or some other non-default init system.

For the systemd-sysv-generator case, the LSB init script is only run if
there is no native systemd unit of the same name, which itself triggers
a Lintian warning (albeit quite a common one); so hopefully if maintainers
are removing lsb-base dependencies as prompted by Lintian, they are also
adding a corresponding /lib/systemd/system/foo.service for each
/etc/init.d/foo in the package.

For the sysv-rc case, sysv-rc in bullseye already depended on lsb-base
so that individual init scripts wouldn't have to.

For other non-default init systems like openrc, yes this could be
a problem.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Jan 20, Simon McVittie <smcv@debian.org> wrote:

For the systemd-sysv-generator case, the LSB init script is only run if
there is no native systemd unit of the same name, which itself triggers
a Lintian warning (albeit quite a common one); so hopefully if maintainers are removing lsb-base dependencies as prompted by Lintian, they are also adding a corresponding /lib/systemd/system/foo.service for each /etc/init.d/foo in the package.

I think that it is time to upgrade the warning, because I understand
that interest in continuing to maintain systemd-sysv-generator is
waning.

I will be happy to assist maintainers who want to add a .service unit to
their package but are unsure about the details.

--
ciao,
Marco

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQnKUXNg20437dCfobLPsM64d7XgQUCY8qqsgAKCRDLPsM64d7X gT6MAQDayOSEsg3Tj2srYY2H59ePAQwkxb5wIJYNnE76R4wifQEA1gfqNeBDPYvc HnFica8VFUQjPTaVFKBm9R8wX4DnOwU=
=GRTg
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 20 Jan 2023 at 14:53, Marco d'Itri <md@linux.it> wrote:

On Jan 20, Simon McVittie <smcv@debian.org> wrote:

For the systemd-sysv-generator case, the LSB init script is only run if there is no native systemd unit of the same name, which itself triggers
a Lintian warning (albeit quite a common one); so hopefully if maintainers are removing lsb-base dependencies as prompted by Lintian, they are also adding a corresponding /lib/systemd/system/foo.service for each /etc/init.d/foo in the package.

I think that it is time to upgrade the warning, because I understand
that interest in continuing to maintain systemd-sysv-generator is
waning.

I will be happy to assist maintainers who want to add a .service unit to their package but are unsure about the details.

I already proposed upgrading the warning, but the answer was that
policy needs to change first:

https://salsa.debian.org/lintian/lintian/-/merge_requests/407

Kind regards,
Luca Boccassi

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 20 Jan 2023 at 15:52:34 +0100, Marco d'Itri wrote:

I think that it is time to upgrade the warning, because I understand
that interest in continuing to maintain systemd-sysv-generator is
waning.

I will be happy to assist maintainers who want to add a .service unit to their package but are unsure about the details.

This seems like a good thing to mass-bug-file about when trixie opens up
for development. As well as the advantages cited in the Lintian tag at
the moment, one big reason to add native systemd units is that a native
systemd unit tells systemd what lifecycle to expect the service to have.

A native systemd unit can specify whether it represents a long-running
daemon like /etc/init.d/ssh (typically Type=forking, simple, exec,
dbus, or notify with the default RemainAfterExit=no) or a batch job like /etc/init.d/sudo (typically Type=oneshot with RemainAfterExit=yes).

systemd-sysv-generator doesn't have that information available to it,
so it has no choice but to generate units that are an awkward compromise
with Type=forking and RemainAfterExit=yes, which is adequate in most
cases, but is not actually fully correct for either of those categories.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi!

On Wed, 18 Jan 2023 at 09:00, Andreas Metzler <ametzler@bebt.de> wrote:

On 2023-01-18 Otto Kekäläinen <otto@kekalainen.net> wrote:

Lintian just started erroring on 'depends-on-obsolete-package
lsb-base' on many of my packages yesterday. There are no new uploads

[...]

Does somebody know what is going on?

Example:
E: mariadb-server: depends-on-obsolete-package Depends: lsb-base (>= 3.0-10)

That is this change
* Remove init.d-script-needs-depends-on-lsb-base and add lsb-base to
obsolete-packages. (Closes: #1019851)

from this commit:

commit 97f742b00553a4dd7ba681aefa4cc164ea263f71
Remove init.d-script-needs-depends-on-lsb-base and add lsb-base to obsolete-packages

The functionality of lsb-base is in the Essential:yes set since
Bullseye. The package itself is now an empty transitional package
(because debootstrap doesn't understand the Provides relationship) which
depends on the new provider of the functionality, sysvinit-utils, which
is also in the Essential:yes set.

Closes: #1019851

Thanks for an exact reply!

About the execution of this change repository-wide:

Is anyone working on feeding https://salsa.debian.org/lintian/lintian/-/blob/master/data/fields/obsolete-packages
to https://janitor.debian.net/scrub-obsolete/ so that at least
Salsa-maintained packages would swiftly get on path to get this
dependency removed (and Salsa-CI failures stopped on this Lintian
error)?

As a side note, it would be cool if the Janitor could also mass add
brackets to Lintian overrides (like done manually in https://salsa.debian.org/lintian/lintian/-/commit/6e8c0487a186e1640fe69e2409544b28e6f26164
on Lintian itself) now after that not backwards compatible change was introduced last summer so that we get it executed repository-wide.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Jan 21, 2023 at 12:53:17PM -0800, Otto Kek�l�inen wrote:

On Wed, 18 Jan 2023 at 09:00, Andreas Metzler <ametzler@bebt.de> wrote:

On 2023-01-18 Otto Kek�l�inen <otto@kekalainen.net> wrote:

Lintian just started erroring on 'depends-on-obsolete-package
lsb-base' on many of my packages yesterday. There are no new uploads

[...]

Does somebody know what is going on?

Example:
E: mariadb-server: depends-on-obsolete-package Depends: lsb-base (>= 3.0-10)

That is this change
* Remove init.d-script-needs-depends-on-lsb-base and add lsb-base to
obsolete-packages. (Closes: #1019851)

from this commit:

commit 97f742b00553a4dd7ba681aefa4cc164ea263f71
Remove init.d-script-needs-depends-on-lsb-base and add lsb-base to obsolete-packages

The functionality of lsb-base is in the Essential:yes set since
Bullseye. The package itself is now an empty transitional package
(because debootstrap doesn't understand the Provides relationship) which
depends on the new provider of the functionality, sysvinit-utils, which
is also in the Essential:yes set.

Closes: #1019851

Thanks for an exact reply!

About the execution of this change repository-wide:

Is anyone working on feeding https://salsa.debian.org/lintian/lintian/-/blob/master/data/fields/obsolete-packages
to https://janitor.debian.net/scrub-obsolete/ so that at least Salsa-maintained packages would swiftly get on path to get this
dependency removed (and Salsa-CI failures stopped on this Lintian
error)?

That's an interesting idea. The current format https://salsa.debian.org/lintian/lintian/-/blob/master/data/fields/obsolete-packages
isn't super machine-readable. Perhaps it could be split into one file
with human-readable hints, and one with straightforward replacements
(e.g. "libtinfo-dev => libncurses-dev" )?

As a side note, it would be cool if the Janitor could also mass add
brackets to Lintian overrides (like done manually in https://salsa.debian.org/lintian/lintian/-/commit/6e8c0487a186e1640fe69e2409544b28e6f26164
on Lintian itself) now after that not backwards compatible change was introduced last summer so that we get it executed repository-wide.

The janitor (or more specifically, lintian-brush) already does this. See e.g. https://salsa.debian.org/multimedia-team/abgate/-/merge_requests/2/diffs

Jelmer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

About the execution of this change repository-wide:

Is anyone working on feeding https://salsa.debian.org/lintian/lintian/-/blob/master/data/fields/obsolete-packages
to https://janitor.debian.net/scrub-obsolete/ so that at least Salsa-maintained packages would swiftly get on path to get this
dependency removed (and Salsa-CI failures stopped on this Lintian
error)?

That's an interesting idea. The current format https://salsa.debian.org/lintian/lintian/-/blob/master/data/fields/obsolete-packages
isn't super machine-readable. Perhaps it could be split into one file
with human-readable hints, and one with straightforward replacements
(e.g. "libtinfo-dev => libncurses-dev" )?

Related, current lintian-brush actually adds lsb-base back if it was removed:

$ lintian-brush --version
lintian-brush 0.145

$ lintian-brush --allow-reformatting --uncertain --yolo --modern

$ git show
commit a0a2bf5d6972348114b6d6d489619353c539bd74 (HEAD -> dev-otto)
Add missing dependency on lsb-base.

Changes-By: lintian-brush
Fixes: lintian: init.d-script-needs-depends-on-lsb-base
See-also: https://lintian.debian.org/tags/init.d-script-needs-depends-on-lsb-base.html
diff --git a/debian/control b/debian/control
index 80edd7be401..240d74914d3 100644
--- a/debian/control
+++ b/debian/control
@@ -454,7 +454,8 @@ Depends: galera-4 (>= 26.4),
- ${shlibs:Depends}
+ ${shlibs:Depends},
+ lsb-base

I have only ever found two bugs in lintian-brush, otherwise it works
perfectly. I wish those who drive changes to Lintian rules would take
one extra step and also collaborate with lintian-brush to automate
fixing the issues instead of relying on all human maintainers to read
Lintian reports and address them manually.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Jan 21, 2023 at 04:48:44PM -0800, Otto Kek�l�inen wrote:

About the execution of this change repository-wide:

Is anyone working on feeding https://salsa.debian.org/lintian/lintian/-/blob/master/data/fields/obsolete-packages
to https://janitor.debian.net/scrub-obsolete/ so that at least Salsa-maintained packages would swiftly get on path to get this dependency removed (and Salsa-CI failures stopped on this Lintian
error)?

That's an interesting idea. The current format https://salsa.debian.org/lintian/lintian/-/blob/master/data/fields/obsolete-packages
isn't super machine-readable. Perhaps it could be split into one file
with human-readable hints, and one with straightforward replacements
(e.g. "libtinfo-dev => libncurses-dev" )?

Related, current lintian-brush actually adds lsb-base back if it was removed:

$ lintian-brush --version
lintian-brush 0.145

$ lintian-brush --allow-reformatting --uncertain --yolo --modern

$ git show
commit a0a2bf5d6972348114b6d6d489619353c539bd74 (HEAD -> dev-otto)
Add missing dependency on lsb-base.

Changes-By: lintian-brush
Fixes: lintian: init.d-script-needs-depends-on-lsb-base
See-also: https://lintian.debian.org/tags/init.d-script-needs-depends-on-lsb-base.html
diff --git a/debian/control b/debian/control
index 80edd7be401..240d74914d3 100644
--- a/debian/control
+++ b/debian/control
@@ -454,7 +454,8 @@ Depends: galera-4 (>= 26.4),
- ${shlibs:Depends}
+ ${shlibs:Depends},
+ lsb-base

FWIW this is a known issue (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946398),
but this fixer is only enabled if you specify --uncertain/--yolo, which specifically
enables changes that might not be correct.

I have only ever found two bugs in lintian-brush, otherwise it works perfectly. I wish those who drive changes to Lintian rules would take
one extra step and also collaborate with lintian-brush to automate
fixing the issues instead of relying on all human maintainers to read
Lintian reports and address them manually.

Thanks, that's great to hear!

The current model actually works quite well from the perspective of lintian-brush: lintian
does the hard work to identify and classify issues and because of its archive-wide
run also shows how many packages are affected.

That makes it much easier to determine what fixers to write. If you
run "make next" in lintian-brush, it will list all lintian tags that don't have a
lintian-brush fixer yet, sorted by number of occurances in the archive.

That said, suggestions for fixers / contributions to lintian-brush are very welcome.
https://salsa.debian.org/jelmer/lintian-brush/-/blob/master/doc/fixer-writing-guide.rst
provides a guide on how to write new fixers.

Cheers,

Jelmer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)