Thread: Documentation building fails on HTTPS redirect (again)

It seems like the issue discussed in [0] is back, but this time for XSL imports
via xsltproc.  The http link now redirects with a 301 (since when I don't know,
but it worked recently):

  $ curl -I http://docbook.sourceforge.net/release/xsl/current/xhtml/chunk.xsl
  HTTP/1.1 301 Moved Permanently
  Date: Fri, 30 Sep 2022 09:20:00 GMT
  Connection: keep-alive
  Cache-Control: max-age=3600
  Expires: Fri, 30 Sep 2022 10:20:00 GMT
  Location: https://docbook.sourceforge.net/release/xsl/current/xhtml/chunk.xsl
  Content-Security-Policy: upgrade-insecure-requests
  Server: cloudflare
  CF-RAY: 752be1544eea0d2e-ARN
  alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400

Changing the links in the documents to be https, and avoid the redirect,
doesn't help unfortunately since xsltproc can't download assets over https.
The lack of https support in libxml2 has been reported, and patches submitted,
a long time ago [1] but there is still a lack of https support.  Looking around
for other mirrors I only managed to find cdn.dookbook.org, which just like
Sourceforge does a 301 redirect.

Installing the stylesheets locally as we document solves the issue of course,
but maybe it's time to move to using --nonet as we discussed in [0] and require
the stylesheets locally?  It's a shame that casual contributions require a big
investment in installation, but it seems hard to get around.

--
Daniel Gustafsson        https://vmware.com/

[0] https://www.postgresql.org/message-id/flat/E2EE6B76-2D96-408A-B961-CAE47D1A86F0@yesql.se
[1] https://mail.gnome.org/archives/xml/2007-March/msg00087.html

Hi,

On 2022-09-30 11:35:36 +0200, Daniel Gustafsson wrote:
> Installing the stylesheets locally as we document solves the issue of course,
> but maybe it's time to move to using --nonet as we discussed in [0] and require
> the stylesheets locally?  It's a shame that casual contributions require a big
> investment in installation, but it seems hard to get around.

docbooks-xml and docbooks-xsl aren't that big (adding 8MB to a minimal debian
install).

However a) we document installing fop as well, even though it's not needed for
the html docs build b) the dependencies recommended by the debian packages
increase the size a lot. Just using our documented line ends up with 550MB.

Perhaps separating out fop and using --no-install-recommends (and other
similar flags) makes it less of an issue?  We probably should work to deliver
a more usable error than what just using --nonet gives you...

Greetings,

Andres Freund

> On 2 Oct 2022, at 03:49, Andres Freund <andres@anarazel.de> wrote:
> On 2022-09-30 11:35:36 +0200, Daniel Gustafsson wrote:
>> Installing the stylesheets locally as we document solves the issue of course,
>> but maybe it's time to move to using --nonet as we discussed in [0] and require
>> the stylesheets locally?  It's a shame that casual contributions require a big
>> investment in installation, but it seems hard to get around.
>
> docbooks-xml and docbooks-xsl aren't that big (adding 8MB to a minimal debian
> install).

Thats true, size wise they are trivial, but it's a shame we seemingly need to
move away from "you don't have to do anything" which worked for years, to "you
need to install X which you are unlikely to need for anything else".
Especially when the failure stems from such a silly limitation.  But, that's
out of our hands, and we can only work on making it better for our
contributors.

> However a) we document installing fop as well, even though it's not needed for
> the html docs build b) the dependencies recommended by the debian packages
> increase the size a lot. Just using our documented line ends up with 550MB.

We have this in the documentation today, but it's not especially visible and
well below where we list the packages:

    "If xmllint or xsltproc is not found, you will not be able to build any
    of the documentation.  fop is only needed to build the documentation in
    PDF format."

I think we should make it a lot more visible.

> Perhaps separating out fop and using --no-install-recommends (and other
> similar flags) makes it less of an issue?  We probably should work to deliver
> a more usable error than what just using --nonet gives you...

I agree with that.

--
Daniel Gustafsson        https://vmware.com/