[pkg-netfilter-team] Bug#981641: FTBFS with an xsltproc error

[Helmut Grohne]

On Tue, Feb 02, 2021 at 04:25:36PM +0100, Arturo Borrero Gonzalez wrote:
> I suspect this might be related to this recent change:
> 
> https://salsa.debian.org/pkg-netfilter-team/pkg-nftables/-/commit/4eb323698ee7d8e50132fb271c0f3aa92c727285
> 
> Could you please check if introducing back docbook-xsl as build-dep fixes the issue?

Mea culpa. My analysis concluded that since there are no docbook files
in the source and there are no xsltproc invocations, that it would not
use xsltproc. I did not anticipate that it would use xsltproc via a2x
from asciidoc. Much less that the usage would be architecture dependent.
I actually verified that my change would not result in changed output
artifacts (as in reproducible), but I only performed the testing on
amd64. So this is how I missed it. I'll pay more attention when running
into asciidoc in future.

I do wonder though whether this really is a bug in nftables. Should
nftables really be concerned with how asciidoc operates? If I have an
asciidoc file and want a manual page, how should I know that I need
docbook-xsl in addition to asciidoc? asciidoc-base already depends on
xsltproc. Maybe asciidoc-base should also quite simply depend on
docbook-xsl?

Of course, that would get us a bigger dependency tree than before.
Quite the opposite of what I wanted to achieve. It would be one with
fewer surprises though. What do you think?

Adding the asciidoc maintainer to Cc.

Helmut