Created attachment 13835 [details] [review]
The patch

Sorry, I disagree with this patch. You say it "should be tunable"
and I don't see why. I'm usually for flexibility, until is screws
the users, and in that case I think it's the latter.
All the documentation and code in libxml2 and on a lot of other places,
like Gnome code etc..., is based on the bact that the top catalog is
in /etc/xml/catalog.
If you want to implement a different scheme maintain your own patches
and own documentation, it's of course a pain but I will not help
bringing unjustified fragmentation at the XML toools chain level.

Daniel

So let me explain why. The NetBSD's Packages Collection (see http://www.pkgsrc.org/) is a self-contained package system. ALL configuration files go, by default, into $PREFIX/etc, which can be changed by the administrator to any other place through a special variable called PKG_SYSCONFBASE.

This is useful to avoid polluting the standard /etc directory. I, for example, set PKG_SYSCONFBASE to /etc/pkg (but many people uses the default, which is /usr/pkg/etc). So, you see: the base system knows nothing about xml/sgml, so /etc/sgml and /etc/xml will not be there, never (except, of course, you set PKG_SYSCONFBASE to /etc). I'm against patching third-party programs because patches get easily out of sync and need to be adjusted in every updated.

Anyway, if you insist in not doing this change, you could (at least), modify the xmllint.c file to display XML_XML_DEFAULT_CATALOG (which is defined at the top of the file) instead of hardcoding the path in the message. That could help us because we could only need to declare those macros trough CPPFLAGS. The same goes for xmlcatalog.c: it could be nice if the definition of XML_SGML_DEFAULT_CATALOG was surrounded by an #ifdef.

Thank you.

> the base system knows nothing about xml/sgml, so /etc/sgml and
> /etc/xml  will not be there, never

  Well, that's FreeBSD decision, not mine. For the record
Sun Microsystem, shich ships libxml2 as part of Solaris OS core
maintain their own patch for this. I see not justification for
the decision of ignoring XML as part of the base operating system.

> I'm against patching third-party programs because patches get
> easily out of sync and need to be adjusted in every updated 

  Well I told you, I know it's gonna be painful. But by deciding
not to provide /etc/xml/catalog as the root toplevel catalog,
you're also deciding to break all the documentation for my software
and also all software based on libxml2 which starts to be quite an
awful lot of code.
Guess who will get the bug reports ? So FreeBSD (or your group
within) decided to make my life painful, why should I ease your
job for doing so ? I honnestly ask the question, you made your
decision unilaterally and I'm supposed to accept the breakage,
and make your life easy, there is something wrong, no ?
  If you don't provide global catalog at the operating system
level state so, make your users aware of the fact and tell them to
use the environment variable XML_CATALOG_FILES to point to their
own catalog. That should work fine, point to the fact that you
decided to not provide the facility, and hopefully I will get less
bug reports.

   Makes sense ?

Daniel

Okay okay. I understand your point of view. But what about this new patch? This just makes things cleaner but does not allow the end user to change it himself if he does not know what he is doing.

(We, in our package system, will take care to patch all required programs to use our "default" value, so end users should have no problem).

Created attachment 13838 [details] [review]
Another patch...

Okay that patch is a reasonnable compromise :-)
Applied and commited,

  thanks,

Daniel

> the base system knows nothing about xml/sgml, so /etc/sgml and
> /etc/xml  will not be there, never

  Well, that's FreeBSD decision, not mine. For the record
Sun Microsystem, shich ships libxml2 as part of Solaris OS core
maintain their own patch for this. I see not justification for
the decision of ignoring XML as part of the base operating system.

> I'm against patching third-party programs because patches get
> easily out of sync and need to be adjusted in every updated 

  Well I told you, I know it's gonna be painful. But by deciding
not to provide /etc/xml/catalog as the root toplevel catalog,
you're also deciding to break all the documentation for my software
and also all software based on libxml2 which starts to be quite an
awful lot of code.
Guess who will get the bug reports ? So FreeBSD (or your group
within) decided to make my life painful, why should I ease your
job for doing so ? I honnestly ask the question, you made your
decision unilaterally and I'm supposed to accept the breakage,
and make your life easy, there is something wrong, no ?
  If you don't provide global catalog at the operating system
level state so, make your users aware of the fact and tell them to
use the environment variable XML_CATALOG_FILES to point to their
own catalog. That should work fine, point to the fact that you
decided to not provide the facility, and hopefully I will get less
bug reports.

   Makes sense ?

Daniel

this should be fixed in libxml2-2.5.3 release,

  thanks,

Daniel