Re: RFC Implementation of SGML/XML Proposal for LSB in Debian
Adam Di Carlo (adam@onshore.com) wrote:
> 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
This is where the proposal of Mark Johnson would fit in nicely. You can use
/usr/share/sgml/html/dtd
declarations
and put all the HTML materials in there. I agree it's an overkill to separate
all this out into separate directories. I suggest we use this approach. If
it really does not make it into the standard we can always rethink this. Having
a standard and following it is a good thing, but let's be practical.
> Are we dropping the fallback derivation of the file name as found in
> section 2 of /usr/doc/sgml-base/sgml_layout.txt.gz ?
The proposed standard doesn't say anything about this (in fact, it only talks
about the contents of the centralized catalogs and the super catalog). I don't
see any reason yet we should drop this feature. It's not in contradiction with
the standard. We can always drop it later if it becomes forbidden.
> > 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.
See below.
> > 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.
You're right.
> > 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.
Excellent idea! Using catalogs for the transition makes it all a lot
easier and simpler (if I understand your proposal correctly). After
the catalogs are in place and SP and OpenSP have been updated, the
other packages only have to move their stuff from /usr/lib to the
new place, update their catalogs and symlink back to /usr/lib
what's needed there until the other tools have been updated (or
am I seeing this to simplistic too). I'm wondering which tools
look under /usr/lib/sgml, besides SP and OpenSP. Is there an
easy way to find this out?
> > 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).
I expect to have something ready before the end of the week:
- the catalog setup you described
- a new tool called `install-catalog` to manage the centralized
catalogs and the super catalog (I think it's better to keep
`install-sgmlcatalog` as it is, besides updating it for the
transition catalog)
Thanks,
Ardo
--
Ardo van Rangelrooij
home email: ardo@debian.org
home page: http://people.debian.org/~ardo
PGP fp: 3B 1F 21 72 00 5C 3A 73 7F 72 DF D9 90 78 47 F9
Reply to: