Re: RFC Implementation of SGML/XML Proposal for LSB in Debian
Ardo van Rangelrooij <ardo@debian.org> 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 Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: