GNU bug report logs -
#79419
"automake --add-missing" should not install an obsolete texinfo.tex file
Previous Next
To reply to this bug, email your comments to 79419 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-automake <at> gnu.org
:
bug#79419
; Package
automake
.
(Wed, 10 Sep 2025 10:18:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Vincent Lefevre <vincent <at> vinc17.net>
:
New bug report received and forwarded. Copy sent to
bug-automake <at> gnu.org
.
(Wed, 10 Sep 2025 10:18:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi,
I had reported the following bug in the Debian BTS, and this is still
an issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882844
In 2017, with GNU Automake 1.15.1: "automake --add-missing" installs
the texinfo.tex file it distributes, which is really obsolete:
2013-02-01.11 while the current version is 2017-08-23.19.
The texinfo.tex file was no longer obsolete with GNU Automake 1.16
in January 2019. But this issue, which has never been fixed, is now
visible again with GNU Automake 1.17:
In the MPFR working copy under Debian/unstable (trixie is probably
also affected):
qaa% rm doc/texinfo.tex
qaa% automake --add-missing
doc/Makefile.am:25: installing 'doc/texinfo.tex'
qaa% grep def.texinfoversion doc/texinfo.tex
\def\texinfoversion{2024-02-10.22}
qaa% grep def.texinfoversion /usr/share/texmf/tex/texinfo/texinfo.tex
\def\texinfoversion{2024-11-04.20}
(where /usr/share/texmf/tex/texinfo/texinfo.tex is the up-to-date
file provided by texinfo).
The issue is that "automake --add-missing" installs the texinfo.tex
file it distributes (which can be very old as seen in the 2017 case)
while there may be a newer Texinfo installed under the standard
texmf directory.
--
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
Information forwarded
to
bug-automake <at> gnu.org
:
bug#79419
; Package
automake
.
(Wed, 10 Sep 2025 21:13:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 79419 <at> debbugs.gnu.org (full text, mbox):
Hi Vincent. As far as I know, --add-missing has never checked for
whether its versions are older. I don't know of a reasonable way to
change this -- it's a common problem, and also inevitable, given
asynchronous releases of everything involved. Instead, it doesn't
install over existing files.
I believe you can stop Automake from dealing with texinfo.tex by
1) specifying the no-texinfo-tex Automake option, or
2) (perhaps better) setting the TEXINFO_TEX variable, or
3) creating doc/texinfo.tex yourself before running it, as in:
ln -s /usr/share/texmf/tex/texinfo/texinfo.tex doc/texinfo.tex
or 4) removing the undesired link/copy afterward (of course).
I realize none of these are really satisfactory, but I can't think of
anything better. I don't think it's feasible for automake to go poking
around the system trying to find other versions of the "missing" files
to compare against. There'd be no way to know what's really wanted,
seems to me.
For example, one could imagine running kpsewhich texinfo.tex and
comparing versions (already prone to problems) ... but you might be
making a test or other hierarchy where you explicitly do not want the
behavior to depend on what the current system has installed.
I'm open to other ideas. --best, karl.
Information forwarded
to
bug-automake <at> gnu.org
:
bug#79419
; Package
automake
.
(Wed, 10 Sep 2025 21:57:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 79419 <at> debbugs.gnu.org (full text, mbox):
On Wed, Sep 10, 2025, at 5:11 PM, Karl Berry wrote:
> Hi Vincent. As far as I know, --add-missing has never checked for
> whether its versions are older. I don't know of a reasonable way to
> change this -- it's a common problem, and also inevitable, given
> asynchronous releases of everything involved. Instead, it doesn't
> install over existing files.
...
> I don't think it's feasible for automake to go poking around the
> system trying to find other versions of the "missing" files to compare
> against. There'd be no way to know what's really wanted, seems to me.
...
> I'm open to other ideas. --best, karl.
This couldn't be the default, because it'd involve talking to the
network, but what about a mode where it retrieves the latest version of
each file that is frequently updated, directly from its official VCS
source? As well as texinfo.tex, I know this would be useful for
config.sub and config.guess at least.
zw
Information forwarded
to
bug-automake <at> gnu.org
:
bug#79419
; Package
automake
.
(Thu, 11 Sep 2025 08:49:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 79419 <at> debbugs.gnu.org (full text, mbox):
On 2025-09-10 15:11:58 -0600, Karl Berry wrote:
> For example, one could imagine running kpsewhich texinfo.tex and
> comparing versions (already prone to problems) ... but you might be
> making a test or other hierarchy where you explicitly do not want the
> behavior to depend on what the current system has installed.
"kpsewhich texinfo.tex" seems to be a way to get the correct path.
But if there is any problem with it, I'm wondering whether the path
should be provided at Automake build time (possibly as a list of
directories, as usual search paths): it would be provided either
by a distribution or by a user who builds Automake.
--
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
Information forwarded
to
bug-automake <at> gnu.org
:
bug#79419
; Package
automake
.
(Thu, 11 Sep 2025 08:58:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 79419 <at> debbugs.gnu.org (full text, mbox):
On 2025-09-10 17:56:22 -0400, Zack Weinberg wrote:
> This couldn't be the default, because it'd involve talking to the
> network, but what about a mode where it retrieves the latest version of
> each file that is frequently updated, directly from its official VCS
> source? As well as texinfo.tex, I know this would be useful for
> config.sub and config.guess at least.
I don't think that this is a good idea, in particular if the files
are not signed (and for texinfo.tex, the user might not want to use
an unstable version). I would rather expect the user to download
the files and put them at some location, with some manual checking.
Then automake should have a way to pick them.
--
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
Information forwarded
to
bug-automake <at> gnu.org
:
bug#79419
; Package
automake
.
(Thu, 11 Sep 2025 21:30:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 79419 <at> debbugs.gnu.org (full text, mbox):
"kpsewhich texinfo.tex" seems to be a way to get the correct path.
Sometimes, but sometimes not, as I said.
Then automake should have a way to pick them.
It already does, seems to me. Put the file you want in place before the
--add-missing run, using whatever method you want, and automake won't
overwrite it. That seems way simpler and more general to me than
creating a bunch of new paths or variables to be checked, just to avoid
running a cp or ln command. I suspect the plethora of configuration
required would just confuse people and/or lead to unintended behavior.
Myself, I use the srclist-update script in gnulib/config/ to keep the
common files in my source trees up to date. --best, karl.
Information forwarded
to
bug-automake <at> gnu.org
:
bug#79419
; Package
automake
.
(Thu, 11 Sep 2025 21:30:03 GMT)
Full text and
rfc822 format available.
Message #23 received at 79419 <at> debbugs.gnu.org (full text, mbox):
but what about a mode where it retrieves the latest version of
each file that is frequently updated, directly from its official VCS
source?
It's useful, but seems far from Automake's core purpose. It seems better
to me as a separate script than as part of Automake.
And that script has already been written, more or less. It's what
gnulib/config/srclist-update does, as to keep the common files up to
date in gnulib -- so everyone else can just get them from there (gnulib)
and not to have trawl around different repos. --thanks, karl.
Information forwarded
to
bug-automake <at> gnu.org
:
bug#79419
; Package
automake
.
(Thu, 11 Sep 2025 22:38:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 79419 <at> debbugs.gnu.org (full text, mbox):
Karl Berry <karl <at> freefriends.org> writes:
> but what about a mode where it retrieves the latest version of
> each file that is frequently updated, directly from its official VCS
> source?
>
> It's useful, but seems far from Automake's core purpose. It seems better
> to me as a separate script than as part of Automake.
>
> And that script has already been written, more or less. It's what
> gnulib/config/srclist-update does, as to keep the common files up to
> date in gnulib -- so everyone else can just get them from there (gnulib)
> and not to have trawl around different repos. --thanks, karl.
+1, it is probably just easier to pull in auxiliary files (e.g.
config.sub, config.guess, texinfo.tex, etc.) from Gnulib. Since those
will be updated daily with changes, if any.
Also, ideally you would use a mirror to not make the Savannah situation
worse. The Savannah git mirror works [1]. Or also the GitHub mirror
maintained by GNU Coreutils maintainers [2].
Collin
[1] https://https.git.savannah.gnu.org/git/gnulib.git
[2] https://github.com/coreutils/gnulib
Information forwarded
to
bug-automake <at> gnu.org
:
bug#79419
; Package
automake
.
(Fri, 12 Sep 2025 00:30:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 79419 <at> debbugs.gnu.org (full text, mbox):
On 2025-09-11 15:29:20 -0600, Karl Berry wrote:
> Then automake should have a way to pick them.
>
> It already does, seems to me. Put the file you want in place before the
> --add-missing run, using whatever method you want, and automake won't
> overwrite it.
This requires manual setup *each time* "automake --add-missing" needs
to be used.
--
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
Information forwarded
to
bug-automake <at> gnu.org
:
bug#79419
; Package
automake
.
(Fri, 12 Sep 2025 22:10:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 79419 <at> debbugs.gnu.org (full text, mbox):
Hi Vincent,
This requires manual setup *each time* "automake --add-missing" needs
to be used.
Well, or writing a tiny script to do whatever you want to do. That's the
real solution, it seems to me.
For texinfo.tex in particular, you could possibly use the TEXINFO_TEX
variable, as I wrote before.
I see no viable alternative in general. I don't want to create new
configuration variables for every file. Sorry. -k
Information forwarded
to
bug-automake <at> gnu.org
:
bug#79419
; Package
automake
.
(Fri, 12 Sep 2025 23:50:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 79419 <at> debbugs.gnu.org (full text, mbox):
On 2025-09-12 16:09:49 -0600, Karl Berry wrote:
> Hi Vincent,
>
> This requires manual setup *each time* "automake --add-missing" needs
> to be used.
>
> Well, or writing a tiny script to do whatever you want to do. That's the
> real solution, it seems to me.
Having something that works with any 3rd-party project is difficult,
while "automake --add-missing" (actually called via "autoreconf -f")
is relatively standard.
> For texinfo.tex in particular, you could possibly use the TEXINFO_TEX
> variable, as I wrote before.
TEXINFO_TEX is intended for packages that have their own texinfo.tex
file. And this is even wrong, because the idea is to update the file
with "autoreconf -f".
--
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
This bug report was last modified today.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.