Re: RFC Implementation of SGML/XML Proposal for LSB in Debian
Ardo van Rangelrooij <ardo@debian.org> writes:
> Adam Di Carlo (adam@onshore.com) wrote:
> > 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.
Ardo, anyone, no comment on this?
> > 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
URL please?
> 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.
Well, I could have a html-legacy directory for the < 4 stuff.
> > 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.
I've always thought 'install-catalog' on Debian at least should handle
this. There's really no reason why package maintainers need to be
burdened. Maybe I should file a wishlist bug on sgml-base for this?
> > 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).
No, I think you're right. Once we've reached the point in transition
where we are actively deprecating /usr/lib/ then we (a) pull
/usr/lib/sgml out of the SGML_SEARCH_PATH for all SMGL/XML tools, and
(b) file bugs on things that break (we're talking woody+1 here
obviously).
> I'm wondering which tools
> look under /usr/lib/sgml, besides SP and OpenSP. Is there an
> easy way to find this out?
Based on 'apt-cache showpkg sgml-base' to see reverse depends on
sgml-base, I see, then trimming out for just processors, I have this
provisional list:
openjade
sgml-tools-2
sp,sgml-base
opensp
jade
sgml-tools
psgml
perlsgml
linuxdoc-tools
This list is even probably too big. Some of these packages don't have
entity managers but rather rely on other packages that do.
> I expect to have something ready before the end of the week:
Excellent.
> - 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)
Sounds like extra work -- couldn't you just symlink the two tools
together?
Well, its your time :)
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: