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:
> > Adam Di Carlo (adam@onshore.com) wrote:
[snip]
> > > 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?
Please do. See also below.
> > > 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 think so too.
> > 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.
So, the list is rather small. Good!
> > I expect to have something ready before the end of the week:
>
> Excellent.
I'm working on the final details.
> > - 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?
No, it was easier to just take a copy and adapting it.
By the way, I renamed the new tool to `update-catalog` which seems much
more appropriate given its purpose. In the near future there will also
be an `install-catalog` doing what you proposed above for the derived names,
but then only for ordinary catalogs. Further, your sgml-catalog-check.pl
will also finally make it in sgml-base but then as `check-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: