Re: MacOS: xsltproc fails with "warning: failed to load external entity"

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Aleksander Alekseev <aleksander(at)timescale(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Subject: Re: MacOS: xsltproc fails with "warning: failed to load external entity"
Date: 2023-01-30 21:01:51
Message-ID: 887800.1675112511@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Aleksander Alekseev <aleksander(at)timescale(dot)com> writes:
>> What we do actually have already is a recommendation to install
>> appropriate MacPorts or Homebrew packages:
>> https://www.postgresql.org/docs/devel/docguide-toolsets.html#DOCGUIDE-TOOLSETS-INST-MACOS
>> and it works okay for me as long as I use MacPorts' version of xsltproc.

> Unfortunately it doesn't work for Homebrew anymore and there seems to
> be only one xsltproc in the system.

Hmm. Seems unlikely that Homebrew would have dropped the package(s)
altogether. But ... poking at this, I discovered that there are
inaccuracies in our docs for MacPorts:

* /opt/local/bin/xsltproc is provided by libxslt, and
/opt/local/bin/xmllint is provided by libxml2, neither of which
will be installed by our recipe as given. You might have pulled
those ports in already to build Postgres with, but if you didn't, the
recipe will fail. I wonder if the Homebrew recipe has the same bug.

* At some point MacPorts renamed docbook-xsl to docbook-xsl-nons.
This is harmless at the moment, because if you ask for docbook-xsl
it will automatically install docbook-xsl-nons instead. I wonder
if that'll be true indefinitely, though.

I also wonder whether we shouldn't point at the meta-package docbook-xml
instead of naming a particular version here (and having to update
that from time to time). The extra disk space to install all the DTD
versions is entirely insignificant (< 2MB).

> Does your:
> xsltproc --help
> ... also say that it uses /etc/xml/catalog path by default?

Both /usr/bin/xsltproc and /opt/local/bin/xsltproc say

--catalogs : use SGML catalogs from $SGML_CATALOG_FILES
otherwise XML Catalogs starting from
file:///etc/xml/catalog are activated by default

However, this appears to be a lie for /opt/local/bin/xsltproc;
what it's apparently *actually* using is /opt/local/etc/xml/catalog,
which is what MacPorts provides.

I repeated the test I did this morning, and this time using --catalogs
with SGML_CATALOG_FILES set to /opt/local/etc/xml/catalog worked for me,
using either copy of xsltproc. I must've fat-fingered it somehow before.
Nonetheless, I doubt that that recipe is worth recommending to MacPorts
users: if they pull in the DTD packages they might as well pull in libxml2
and libxslt, and then they don't need to adjust anything.

In short, I think we need to update J.2.4 to say this for MacPorts:

sudo port install libxml2 libxslt docbook-xml docbook-xsl-nons fop

and I strongly suspect that the Homebrew recipe has a similar oversight.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2023-01-30 21:02:04 Re: Authentication fails for md5 connections if ~/.postgresql/postgresql.{crt and key} exist
Previous Message Jacob Champion 2023-01-30 21:01:29 Re: Authentication fails for md5 connections if ~/.postgresql/postgresql.{crt and key} exist