FYI
On 20/09/2026 18:31, Simon McVittie wrote:
On Wed, 22 Oct 2025 at 01:51:44 +1300, Amos Jeffries wrote:
On Tue, 21 Oct 2025 00:00:05 +0200 Santiago Vila wrote:
automake="automake (>= ${AM_VERSION})"
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)
I believe that should be:
automake="automake (= ${AM_VERSION})"
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.
Otherwise the same issues will reappear with [automake 1.20] saying
"missing [aclocal-1.19]"
Yes, it seems that libltdl-dev does hard-code a specific version at
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
See the parallel discussion on the auto* mailing list:
https://lists.gnu.org/archive/html/autoconf/2026-09/msg00006.html
Alastair
--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
e: [email protected], im: @alastair:mckinstry.ie
https://mastodon.ie/@amckinstry
