[bug#65479] [PATCH core-updates v3 02/63] search-paths: Add $XML_CATALOG_FILES and $SGML_CATALOG_FILES.

[Ludovic Courtès]

Hello,

Bruno Victal <mirai@makinata.eu> skribis:

>> The way I see it, we’d define in (guix search-paths) only search paths
>> that are repeated in several different places, like $SSL_CERT_DIR.
>
> I didn't do an exhaustive search of what applications under the sun make use
> of the XML_CATALOG_FILES and SGML_CATALOG_FILES environment variables but I
> can say that we were missing them in a few crucial packages. In the packages
> where I added these search-paths (spans across various patches) I went through
> their manpages and in some occasions had to grep through their source code to
> confirm this.
>
> […]
>
>> $XML_CATALOG_FILES has 2 users, one of which looks dubious and should
>> probably be audited, and $SGML_CATALOG_FILES has only 1 user.  Thus, the
>> status quo seems good to me.
>
> Which package are you finding its use dubious?

On ‘master’, ‘XML_CATALOG_FILES’ is the search path of
‘perl-app-xml-docbook-builder’ and ‘libxml2’.  The first looks more like
a hack, with this comment:

  ;; xsltproc's search paths, to avoid propagating libxslt.

> By 2 users I presume the ones within the commit which isn't the end of the 
> tale,
> see patches 03-04, 15, 18 and 24-25.

Oh my bad, I guess I didn’t see the whole series.

> In v1/v2 their use was much more pronounced until Maxims suggestion of 
> introducing
> %libxslt-search-paths [1] to avoid top-level import cycles. (whilst also being
> a more concise way to convey this information without manually duplicating it
> when cycles did occur in v2)
>
> $SGML_CATALOG_FILES actually has other users, opensp [2], libxml2 and libxslt
> come to mind and are used in subsequent patches within the series.

Alright.

Sorry for being late to the party; maybe these comments of mine are
completely off for ‘core-updates’, apologies.

Ludo’.