Support usage without XML_MAIN_CATALOG

[jtojnar]

Problem description

On NixOS we do not have any central XML catalog, only list of catalogs in XML_CATALOG_FILES produced from dependencies of a package.

Expected behavior

daps should work without XML_MAIN_CATALOG.

Steps to reproduce the behavior

Change XML_MAIN_CATALOG to non-existing file.

For now, I have created a rough patch to fix this. Would merging something like this acceptable?

Edit: libxml 2.9.7 allows us to greatly simplify the patch.

[fsundermeyer]

Thanks for the "rough patch"! Looks good at a first glance. I will have a deeper look into this once I have finished issue #430.

The problem with the second patch is that assuming everyone has libxml 2.9.7 will lead to even more troubles, since the "" is not backwards compatible ;-((.

BTW: (Maybe this is interesting for you...) At SUSE we are currently rolling out a new way of dealing with catalog files (@Vogtinator: correct me in the following if I am wrong): Catalog files from different packages are all dropped in /etc/xml/catalog.d/ . The script https://github.com/openSUSE/sgml-skel/blob/master/update-xml-catalog generates a default catalog (/etc/xml/catalog-d.xml) from all files in /etc/xml/catalog.d/ . Every time a package makes a change in /etc/xml/catalog.d/ it generates a new /etc/xml/catalog-d.xml in post-install to make sure it contains the latest changes.

This approach makes sure that

• catalogs are not scattered all about the file system, but are located in a single location
• reduces catalog delegation to a minimum (one catalog per application/packkage should be enough)
• the main catalog is always up-to-date and is the single catalog that needs to be queried

[jtojnar]

I am not a fan of the rough patch since it basically replicates the functionality of libxml but it is your call, we would be fine with applying the simple one downstream like we do for gtk-doc, shadow and other.

The catalog.d makes sense for classical (stateful) distributions but NixOS is trying to avoid global state as much as possible, for example, there is no central location. We could create personalised catalog files for each package from its dependencies but I find environment variables much more convenient than file manipulation (weren’t it for the only recently fixed libxml bug).