Re: Specifying dependencies more clearly

[G. Branden Robinson]

Hi Alex,

At 2022-11-08T13:26:21+0100, Alejandro Colomar wrote:
> I've always had trouble installing the correct dependencies for groff,
> since depending on what you compile you might need some more or some
> less dependencies, and there's not a clear list of what you need for
> what.

I'm sorry to hear this, because it is one of the points I have tried
consciously to clarify.

> I suggest that you add a very schematic list similar to the one I added for
> the Linux man-pages project:
> 
> <https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/INSTALL#n73>
> 
> BTW, I acknowledge, that this list in the man-pages is not complete, because
> part of it is split into another file:
> 
> <https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/RELEASE#n14>
> 
> However, that's something I did on purpose, since distributing and
> installing from source are completely unrelated processes.

groff has a similar challenge; building it from a distribution archive
("release") has significantly fewer requirements than building from a
repository, especially now.  The groff 1.23.0 distribution archive will
no longer require a TeX installation to build our Texinfo manual.  But
since most people probably didn't try to build that anyway, I guess the
most noticeable reduction is that a yacc program won't be required.

As I said, I've tried to make this stuff clear.  groff's "INSTALL.REPO"
does tell the reader to consult "INSTALL.extra"; maybe you have a
suggestion for how I can make that more noticeable.

Not everything that a groff build depends on is a command, and some
components don't even have a man page, like the troublesome URW fonts.
It is thus tough for me to have a terse list of section 1 man page
references as you do.  I furthermore try to be ecumenical regarding
packaging systems, and not refer to requirements in terms of, say,
Debian package names.[1]

Another of the things I have tried to do is ensure that we have helpful
and communicative Autoconf tests for dependencies.  I have also revised
the configuration banner to communicate more relevant information.

GNU Troff version 1.23.0.rc1.3365-2653e-dirty
----------------------------------------------------------------------
 installation directory prefix    : /usr/local
 C++ compiler and options         : g++ -Wall -Wextra
 use libgroff's memory allocator  : no
 C compiler and options           : gcc -Wall -Wextra
 Perl interpreter version         : 5.32.1
 X11 support                      : enabled
 X11 app defaults directory       : /usr/local/lib/X11/app-defaults
 'groff -l' uses print spooler    : lpr
 use URW fonts for PDF output     : yes
 URW fonts directory              : /usr/share/fonts/type1/gsfonts/
 preconv can use uchardet library : yes
 can build groff.dvi, groff.pdf   : yes
 tests can use poppler PDF tools  : yes
----------------------------------------------------------------------

In groff 1.22.4, we didn't report as much information--not even the
identity of the C++ compiler, even though far more of groff is in C++
than C.

Let me know your thoughts.

Regards,
Branden

[1] I remember well the arrogance with which Red Hat Linux partisans
    (and staff) handled its market position in the late 1990s and early
    2000s.  Even Debian founder Ian Murdock wanted to throw up his hands
    and "standardize" on the repellent RPM package format[2], I think in
    part due to the Linux Standard Base canonizing it--but then Ubuntu
    came along and put a million free CD-ROMs into the hands of the
    people, abruptly arresting Red Hat's play for supremacy.  They
    didn't give up much in the long term--systemd was a much more
    successful play for domination of the GNU/Linux ecosystem.  The real
    "Freedom Zero" is to eat what you're fed, or starve, no?

[2] This was, however, years after he'd vacated the project leadership
    role, and my assessment of the sentiment of the Debian Project at
    the time was that the sentiment of its developers was strongly
    against such a disruption.

signature.asc
Description: PGP signature