Dear maintainer:

The new automake package (1.18) does not have a versioned package name
anymore, and it's called just "automake". Therefore this line in debian/rules
of libtool:

echo 'automake=automake-${AM_VERSION}' > debian/libltdl-dev.substvars

should be changed to something like

automake="automake (>= ${AM_VERSION})"

Currently, packages which BD on libltdl-dev (for example, valdrind)
fail to build with this error:

   package: sbuild-build-depends-main-dummy
   version: 0.invalid.0
   architecture: amd64
   status: broken
   reasons:
    -
     missing:
      pkg:
       package: libltdl-dev
       version: 2.5.4-6
       architecture: amd64
       unsat-dependency: automake-1.18:amd64


and there are many of them (so using "serious" as in "breaks other packages")

(cc Eric Dorland in case he has something to add).

Alternatively, automake could have a Provides: automake-1.18, but I think
the above would make that unnecessary, as "automake-1.18" has never
actually existed as a virtual package.

Thanks.

This bug also causes FTBFS on packages using dh_autoreconf.
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1118303#10>

On Tue, 21 Oct 2025 00:00:05 +0200 Santiago Vila <sanvila@debian.org> wrote:
 > Package: src:libtool
 > Version: 2.5.4-6
 > Severity: serious
 >
 > Dear maintainer:
 >
 > The new automake package (1.18) does not have a versioned package name
 > anymore, and it's called just "automake". Therefore this line in
debian/rules
 > of libtool:
 >
 > echo 'automake=automake-${AM_VERSION}' > debian/libltdl-dev.substvars
 >
 > should be changed to something like
 >
 > automake="automake (>= ${AM_VERSION})"
 >


I tried to comment out the echo line from debian/rules and the packages
build and install fine. The debian/rules file uses script aclocal to
find out AM_VERSION so I suspect it makes no sense to use this value as
a dependency. If the packages depend on some versions of automake it
could be specified explicitly in debian/control. If the aclocal
computation is preserved for some reason the rules line could be changed to

echo 'am_version=${AM_VERSION}' > debian/libltdl-dev.substvars

and then use

automake (>= ${am_version})

in debian/control.

      - Tommi Höynälänmaa

We believe that the bug you reported is fixed in the latest version of
libtool, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1118477@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Alastair McKinstry <mckinstry@debian.org> (supplier of updated libtool package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Tue, 21 Oct 2025 12:49:42 +0100
Source: libtool
Architecture: source
Version: 2.5.4-7
Distribution: unstable
Urgency: medium
Maintainer: Alastair McKinstry <mckinstry@debian.org>
Changed-By: Alastair McKinstry <mckinstry@debian.org>
Closes: 1118477
Changes:
 libtool (2.5.4-7) unstable; urgency=medium
 .
   * Fix libtool automake dependency handling. Thanks to Santiago Vila.
     Closes: #1118477
Checksums-Sha1:
 ffd244aa8dd1b92182d840a5dc1775a34bdd4934 2240 libtool_2.5.4-7.dsc
 9b059ee574c48b6e0bd0b600816c053b2e7d7656 37796 libtool_2.5.4-7.debian.tar.xz
Checksums-Sha256:
 5f0828de84d75ccfb41a13aef08f67106540ebc367e9d2f89fb233eedd77812d 2240 libtool_2.5.4-7.dsc
 77d315f055d65baff90d987d577a4de2b2d77d0826c42e23fcc7129e9406566d 37796 libtool_2.5.4-7.debian.tar.xz
Files:
 eb40a83ba19a08cf13bd241ebacb7141 2240 devel optional libtool_2.5.4-7.dsc
 2777682a21005dcee40173de8e24d1db 37796 devel optional libtool_2.5.4-7.debian.tar.xz
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEgjg86RZbNHx4cIGiy+a7Tl2a06UFAmj3d9EACgkQy+a7Tl2a
06Vf1g/+N32nSh24w3fNxSbZAaUyMcGjB1nu57XRyle5XyacamS0lQ+btiYuwJ4f
uTiSnkTG24xGnIHT0ACZr+5H9abAhBAduLeKLrP7Apt3n0zbC6AyYOZACvmZ6E68
Kwtq2WJbj6VvgDTDN4149TdKjcjo5ha3oi46wAgOOmMdW4rorUNbTL01Iea1LOJJ
D7zk6FZ4hN7kmSugOxo2Bhle1H1BTYsy9EUeHsQ8zEIF5pq2uvk4T8otKb488wMp
eIAiZHF7sI6lYzi1n0L8jEwAiJ7BALvvnjd4tmG3LbLyVg4szUrP8uADfOw7ynVX
hJi/BPl0ChCeVLlL7EEr8OdtLcFjnXwxT/xZ0ri+MnV48QJeVzRIWJJh5zj5wsjS
ay39CRiLpT8L2CwBn6nwh3c31SHxCLRs9hTZL0kCsYSxQ7sw4wIT0V//RMI+6UN+
3iX/rp7WbFT+aqheEzuT+TTk6v6KG/sl7WZA/MRopCgN77CbeOSA0xVCqd+G2mWj
REoqP3tov4BgQ01+M1FG49VcJwpvenwR8dFU1fixjPizI7N9RCLWS+NYxqgGoDK/
3pyCefA7x1GlmwqGUgJJZ7q3sFcyZWZ4u1MjSYoH2EeqJfl29fA0wKKzdUB2SMZY
q8WKl4A5ROQFLHKuJs0MBn+C1rUxDAVG5dlvveXmbKhvGgkXRYU=
=5J9X
-----END PGP SIGNATURE-----

On Tue, 21 Oct 2025 00:00:05 +0200 Santiago Vila wrote:
  Therefore this line in debian/rules

I believe that should be:

   automake="automake (= ${AM_VERSION})"


Otherwise the same issues will reappear with automake 1.19 saying
"missing aclocal-1.18"


Cheers
Amos

In fact automake's version number has an epoch, so to be a meaningful
version constraint this would have to be automake (>= 1:${AM_VERSION}),
which at the time of writing should generate a dependency on:

     automake (>= 1:1.19)

Unfortunately that won't work, because that would only match a version
of automake versioned *exactly* 1.19, and a complete Debian package
version like 1:1.19-2 isn't an exact match for that. The (= ) dependency
syntax is usually only usable within a single source package, not
between source packages.
build-time: for example /usr/share/libtool/configure mentions
am__api_version='1.19' and looks for automake-${am__api_version} and
aclocal-${am__api_version}). At the moment, this works, but as soon as
automake is updated to 1.20, it will fail.

Do other packages depend on libltdl-dev shipping a pre-generated
Makefile.in, configure and aclocal.m4 for itself, or are the packages
that regressed with the new Automake version just picking up
m4 macros from libltdl-dev's aclocal.m4 accidentally?

Having libltdl-dev ship these generated files seems really fragile: they
contain a lot of implementation details that are going to change over
time. If other packages don't actually need these files, then dropping
them from libltdl-dev would bypass this whole class of issue.

Or, if it's necessary to have files in libltdl-dev that hard-code a
specific automake API version, then I think it would have to generate a
dependency on something like

     automake (>= 1:${AM_VERSION}), automake (<< 1:${AM_NEXT_VERSION})

where AM_VERSION would be 1.19 at the time of writing, and
AM_NEXT_VERSION would currently be 1.20. And then libtool would need a
binNMU every time there is a transition to a new new Automake API
version, to update these dependencies to the new version range. Luckily,
all the files that hard-code Automake API version 1.19 seem to be in
libltdl-dev (which is Architecture: any and therefore can be binNMU'd),
not in the libtool binary package (which is Architecture: all and can't
be updated without a sourceful upload).

It might be better if automake still had a versioned Provides for
automake-${AM_VERSION}, preferably autogenerated at automake's own
build-time instead of being hard-coded - and then libltdl-dev could
return to having a dependency on automake-${AM_VERSION} if it needs to.
The semantics could be, for example:

* depend on "automake" if you will run automake, aclocal, etc.
* depend on "automake (>= 1:x.y)" if you need functionality that was new in
   automake x.y but is also expected to be provided in all newer versions
* depend on "automake-x.y" if you will run automake-x.y, aclocal-x.y, etc.
   (best avoided, but some specific packages might need it)

     smcv

FYI

See the parallel discussion on the auto* mailing list:

https://lists.gnu.org/archive/html/autoconf/2026-09/msg00006.html

Alastair