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
