Ardo van Rangelrooij <[EMAIL PROTECTED]> writes: > Initially /usr/lib/sgml/catalog was to be symlinked to the super > catalog, but then psgml didn't work anymore. Apparently psgml > doesn't support CATALOG (the xemacs version does). To prevent > other things from breaking too I've decided to make the symlink > as described above.
Ouch. This means that any package that looks for a catalog in /usr/lib/sgml/catalog will only get the stuff that was installed at the time when the new sgml-base is installed, correct? > This means that we now first have to adapt the SGML tools to look > at the super catalog and understand the CATALOG directive. Only > then we can start moving the stuff currently under /usr/lib/sgml > to /usr/share/sgml. Well, any packages installed *after* the sgml-base installation, and using the new install-sgmlcatalog, the catalog snippets installed using the new system will not be available in the catalog symlink in /usr/lib/sgml/, right? Will the old snippets in /etc/sgml/transition.cat be removed as their new deletegated CATALOG entries are added to the new /etc/sgml/catalog? Any package using /etc/sgml.catalog will break, I think -- right? > If anybody needs any help with this let me know. I'm willing to do > NMU's, test packages, etc. In the meantime I'll also integrate all > the policy related docs into a single doc and work on some new tools > to support ordinary catalogs. What's an "ordinary catalog"? Can you file a bug against psgml that it doesn't understand the CATALOG directive? It seems that understanding that directive is a baseline requirement for any debian SGML/XML system that attempts to understand catalogs at all... -- .....Adam Di [EMAIL PROTECTED]<URL:http://www.onShore.com/>
