Ardo van Rangelrooij <[EMAIL PROTECTED]> writes: > The transition will consists of several steps: > > 1. setting up the new structure while retaining the old one
It's a bit debatable how much symlink madness is required. I mean, for SGML stuff, people are going to be using FPIs almost exclusively. For instance, lets take sgml-data. Do I really have to make symlinks fro /usr/lib/sgml/dtd/html-1.dtd to /usr/share/sgml/html-1/ ? I find that it's generally only XML stuff where the document authors need to accomodate (hypothetical) tools which don't understand SGML Open Catalog formats. Thus /usr/lib/sgml/dtd/xhtml-1.0 should probably be symlinked to /usr/share/sgml/xhtml-1.0. Regarding the setup of the new structure, I wouldn't mind a bit of clarification regarding the structure of the HTML materials. Should I really make, under /usr/share/sgml: html-4.01 html-4.0 html-3.2-style html-3.2 html-3.0 html-2.0 mozilla-2.0 msie-3.0 msie-2.0 hotjava Are we dropping the fallback derivation of the file name as found in section 2 of /usr/doc/sgml-base/sgml_layout.txt.gz ? > 2. adapting all affected packages to use the new structure > 3. removing the old structure > > In the first step each package with files under /usr/lib/sgml has to put the > these files under both /usr/share/sgml and /usr/lib/sgml. This can be done > either by simply putting a copy under /usr/lib/sgml or by symlinking from > /usr/lib/sgml to /usr/share/sgml. Since we're talking about only a few MBs > in size in total, the first solution is probably the easiest to > achieve. Oy. This is going to suck for me, as the sgml-data maintainer. > In the second step we have to adapt each SGML application to look under the > new structure for the SGML files. This is the most challenging > part. The tools need to be adapted to look under *both* /usr/lib/sgml and /usr/share/sgml during the transition period. You should state this explicitly. > The third step is simply removing from each affected package the files under > /usr/lib/sgml. Yes, once all the DTDs and entities have moved. Then, the tools can be adapted to stop looking in /usr/lib/sgml. > 2. Support > > The sgml-base package will provide support to maintain the centralized > catalogs and the super catalog by adapting `install-catalog`. During the > transition both the old and the new structure (w.r.t. the catalogs) will be > supported. > > There will be no support for maintaining the structures themselves. I'm a little confused -- after this is in place, at what point is it safe for SP and OpenSP to stop looking in /etc/sgml.catalog and start looking in /etc/sgml/catalog ? I think it might make more sense for the first transition of sgml-base to carte-blanche migrate all the materials from /etc/sgml.catalog into /etc/sgml/catalog (possibly delegated to /etc/sgml/transitional.cat). As new packages provide catalogs, the legacy materials are removed from /etc/sgml/transitional.cat and provided in /etc/sgml/<file> to which a delegated reference is made in /etc/sgml/catalog etc as per the spec. Moreover, sgml-base would remove /etc/sgml.catalog and make that a symlink to /etc/sgml/catalog. SP and OpenSP, for instance, could be trained to use /etc/sgml/catalog at any point after that, using a versioned depends on sgml-base. > 3. Conclusion > > The first thing to do is to have the sgml-base support in place. I'll also > setup a web page with the type and status of all affected packages. With type > is meant SGML application and/or DTD, stylesheet, etc. > > After that we can start working on the transition itself. Do you have an ETA for this? This seems less and less likely to happen for woody. Having an ETA would be helpful because I can start doing the preminary stuff, such as changing the implicit search path and catalog path, and moving around the sgml-data materials (which are legion). -- .....Adam Di [EMAIL PROTECTED]<URL:http://www.onShore.com/>
