[csw-maintainers] docbook, dependencies, what do we want...?

[Ben Walton]

Hi All,

Phil and I have been discussing this for the last few days and I
thought I'd open it up to everyone else, as your input is likely
valuable here.

I've put together a docbook dtds package that provides xml and sgml
dtd files for various versions of the docbook standard.  At
installation time, the xmlcatalog tool is used to 'register' the newly
installed catalog files so that consumers of dtds can find them.  This
sets up a dependency on the libxml2 package (provider of xmlcatalog).

As I modeled this package on the one found in rhel5, I also setup a
dependency on openjade.  This one is a little tenuous though, as the
dependency is basically conditional on some other stylesheets having
been installed on the system before the docbook dtds (which may be a
legacy rpm issue and not valid anymore).  The postinstall script looks
for stylesheets and if it finds them, registers the dtds in the
openjade catalogs.  Phil doesn't like this and I'm not going to defend
it either, as I was simply replicating faithfully the package stack in
another platform to get to my ultimate goal (packaging git).

I see a few options here to make this better:

1. Leave it as is, since there is a basis for doing this provided by
   at least one other distro (more when you look at rhel derivatives).
2. Drop the dependency but still do the postinstall things if both
   stylesheets _and_ openjade are detected.
3. Drop the dependency, remove this chunk of the postinstall script,
   which leaves it up to the user to do the registration if
   required/desired.

After looking into it a bit more, and comparing how Debian's approach
to compared with the Redhat approach I mimicked, I think I like option
3 the best.

...So, in our discussions, a few other things have come up that I
think are worthy of a wider audience for discussion since these base
packages may prove useful down the road for others.

1. Provide a more generic 'plugin' system for these packages to make
   option 2 above simpler.
2. Package something like:
   http://freshmeat.net/projects/dbsgmltoolbox/, which would provide a
   'stack in a box' type approach to these tools.

Having mulled this over for a few days since Phil proposed it, I'll
lay out my opinions/thoughts on them and then let others whack the
pinata.

As for the 'plugin' system, I think that's more involved than we need
to be.  It doesn't seem that either Debian or Redhat do this.

Although they have slightly different approaches, both Debian and
Redhat rely on either their libxml2 package and/or their own catalog
manipulation tools.  Debian has much smarter machinery for doing this
(via debhelper) and has made use of their stronger dependency system
(eg: Suggests for optional dependencies), but overall they take a
similar approach to Redhat for delivery.  To me, this seems like an
unnecessary moving part.

With regard to the dbsgmltoolbox idea, I would suggest that bundling
all those apps into packages is worthwhile iff there is a need for
them.  As it seems that the xmlto package is the first csw application
that calls for full blown dtd/xsl/xml stuff, I don't see this need.  I
say don't build it until its needed (borrowing from the "you aren't
going to need it" philosophy).

So my questions to everyone are:

1. Does anyone see a need for more tools to register dtds and
   stylesheets?  If so, should they be built now or when they're
   actually needed?
2. Does anyone have need for the type of tools provided with
   dbsgmltoolbox now?  If so, I can package them up (since I opened
   this can of worms).  I'm not about to spend time on something
   nobody is interested in though.
3. What does everyone think about the dependencies for the docbook
   dtd's package?  I'd like to get this resolved asap so that docbook
   xsl can be released and then finally xmlto.

Thanks
-Ben
-- 
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20081221/d5d69a0f/attachment-0001.asc>