GNU bug report logs - #79052
epsf.tex: New file

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Simon Josefsson <simon <at> josefsson.org>
To: Bruno Haible via Gnulib discussion list <bug-gnulib <at> gnu.org>
Cc: bug-automake <at> gnu.org, Bruno Haible <bruno <at> clisp.org>,
 Karl Berry <karl <at> freefriends.org>
Subject: Re: epsf.tex: New file
Date: Sat, 19 Jul 2025 21:28:03 +0200

[Message part 1 (text/plain, inline)]

Bruno Haible via Gnulib discussion list <bug-gnulib <at> gnu.org> writes:

> Having said that, I would be in favour of retiring the DVI format from
> the GNU Coding Standards. The DVI format was commonplace in the 1990ies,
> but lost popularity to the PDF format starting 2008 (when PDF became an
> open standard). Nowadays, even the math arXiv does not offer DVI as a
> download format any more [1]. But this needs to be done through the
> proper channels: first the GNU standards, then GNU Autoconf and Automake.

Right.  I would say that the days of the DVI and PS formats are probably
long gone, and definitely as a default format.  PDF has won.

I tried to find any strong recommendation about DVI in the "standards"
and "maintain" manuals, but couldn't find anything.  There are some
references to DVI that may better be to PDF but as far as I could tell,
everything about documentation formats beyond *.info files are optional:

https://www.gnu.org/prep/standards/standards.html
https://www.gnu.org/prep/maintain/maintain.html

So is this about changing automake/autoconf then?

I suppose one change is to make autoconf/automake try to build the PDF
manual at 'distcheck' instead of DVI, but I think that is a more
difficult change: 1) it requires additional tools not otherwise
mentioned in the documents or are normally installed on people's
machines, and 2) the above manuals say special things about 'texi2dvi'
but nothing about the same tools for PDF.  Do we really want to add new
requirements for PDF that haven't been part of these documents, at this
point in time?

Maybe it is sufficient for 'make distcheck' to attempt to build the Info
manual, which I think is already the case?  And then simply drop the
attempt to build *.dvi by default like the attached (untested) patch?

What kind of problems would attempting to build the DVI or PDF manual
really catch these days, which aren't already triggered by attempting to
make the *.info manual?

What is there in autoconf to change?  I couldn't find anything obvious
related to DVI.

/Simon

diff --git a/lib/am/distdir.am b/lib/am/distdir.am
index e21c5a7cc..04113bf25 100644
--- a/lib/am/distdir.am
+++ b/lib/am/distdir.am
@@ -439,7 +439,8 @@ AM_RECURSIVE_TARGETS += distcheck
 endif %?SUBDIRS%
 
 # Exists only to be overridden by the user if desired.
-AM_DISTCHECK_DVI_TARGET = dvi
+# Used to be 'dvi'.
+AM_DISTCHECK_DVI_TARGET =
 
 # This target untars the dist file and tries a VPATH configuration.  Then
 # it guarantees that the distribution is self-contained by making another

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.