Hello,

Lintian checks whether the package build depends on libtool or
dh-autoreconf, but this is no longer needed as dh depends on
dh-autoreconf now.

I remove the obsolete files in the clean rules and use dh_autoreconf,
but lintian can not see it as the obsolete files are still present in
sources.

Thanks,

Nicolas.

tags 1102136 + moreinfo
thanks

Hello,

Thanks for reporting this bug. I'll need more info to make a change, as
I'm not familiar enough with this issue.

Could you point me to a package or give me concrete examples of when the
tag should not be emitted?

Cheers,

Hi,

* Louis-Philippe Véronneau <pollo@debian.org> [2025-05-22 09:43]:

https://udd.debian.org/lintian/?packages=gcc-h8300-hms<_overridden=on

Here is the rules files, it removes the obsolete libtool files and run
dh_autoreconf:

https://salsa.debian.org/debian-lego-team/gcc-h8300-hms/-/blob/master/debian/rules?ref_type=heads#L29

In lintian, it checks the dependency on libtool | dh-autoreconf:

https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/BuildSystems/Autotools/Libtool.pm#L66

But as debhelper depends on dh-autoreconf, this would be a redondant
dependency.

I however have no idea on how the check could be changed.

Nicolas.

Someone could also add ltconfig etc to debian/clean or even do a "mv ltconfig ltconfig.old"
somewhere and try doing something else to actually not use libtool.

Given that lintian is a static checking tool, it is really hard for it to
actually detect N number of patterns when someone is not actually using
libtool to do things despite when files triggering those checks are clearly present.
This is probably one of those cases wherein we would need to as the maintainer
to actually add an override.

Maybe the severity of this could be lowered in the best case.

For this package in particular, it is probably best to have the override be
there as it is. Or otherwise, for better package quality, you might want
to re-pack obsolete files altogether.

@pollo: what do you think?

Thanks
Nilesh

And with respect to this part of the bug report, it appears to me that something
in the check ought to be changed.

Debhelper depends on dh-autoreconf and dh-autoreconf depends on libtool.
So as such both the checks are redundant.

The check in question that we talk about it is:

|    $self->pointed_hint('ancient-libtool', $item->pointer)
|      if $item->basename eq 'ltconfig'
|      && $item->name !~ m{^ debian/ }sx
|      && !$self->libtool_in_build_depends;

`libtool_in_build_depends` checks for "dh-autoreconf | libtool".

It seems that when the check was added, it was added with the assumption that
build depending on either of the two would mean that the maintainer is going
to run them in d/rules and hence this tag was not
triggered if a B-D on dh-autoreconf or libtool was found.

However, with debhelper depending on these now, we can think of modifying checks
in 2 ways:

1. Assume that if a package build depends on debhelper it will always run autoreconf
and we will not have the ancient libtool issue ever. This does not work when packages
start to override dh_autoreconf and do not run dh_autoreconf again. I can see some
packages doing that [1] but not many in number. This would fix the problem for the
package in question (gcc-h8300-hms) as well.

2. Drop the check on `libtool_in_build_depends` altogether and just assume that whenever
we see these files it is going to be a problem. But this would mean that FPs will be
triggered.

Both of them appear not optimal to me. @pollo again, any opinions?

[1] https://codesearch.debian.net/search?q=override_dh_autoreconf+path%3Adebian%2Frules&literal=1&page=13

Thanks
Nilesh