Re: where is sdocbook-xml
Adam Di Carlo writes:
> Mark Johnson <mark@phy.duke.edu> writes:
>
> > Yeah, I have various versions of the simplified docbook-xml, but none
> > have been uploaded because:
> >
> > - I'm not yet an official maintainer (I still haven't heard back.)
>
> I can "sponsor" for you.
I think all that's needed is an OK from the DAM (Developer Account
Manager) and to get a machine account.
>
> > - We haven't agreed on where the files should be installed.
>
> Yes, it's pretty easy to write your rules files such that it's easy to
> move the dirs around later.
>
Already did that.
> I would suggest you get the packages uploaded even based on your
> suggested structure, and then we can change it later.
>
Should I do that, or just put in the /usr/lib/sgml parts? Lemme know
and I'll get them ready.
(By "full setup" at the bottom I meant both /usr/lib/sgml/ and
/usr/share/sgml/.)
> deb http://dulug.duke.edu/~mark/debian ./
>
> and
>
> deb http://dulug.duke.edu/~mark debian/
>
> Neither work.
Hmm. I'll fix it.
> > We _really_ need a virtual package scheme for XSL stylesheets, the
> > virtual package (docbook-xslt-tools??) would play the role for xsl
> > that jade does for the dsssl stylesheets.
> >
> > Unlike the case with jade and dsssl, there are a zillion xslt
> > processors. And most of them won't work with the docbook xsl
> > stylesheets. (I can't get the current xalan package to work, for
> > example.) Specific packagees would have to be built that would
> > "provides" docbook-xslt-tools.
>
> Why wouldn't it just provide 'xsl-processor'. Likewise, jade/openjade
> should provide 'dsssl-processor'. Isn't this what you're asking for?
>
No, that won't do it. Only a subset of the xslt processors will work
with the docbook xsl stylesheets. We need some easy way for users to
install packages that'll work for _docbook_ xsl processing.
The reasons are that some xslt processors have less than complete XSLT
implementations, and that Norm (sometimes) uses special extensions
only supported by a subset of the xslt processors. The situation
doesn't allow for generic specification of processors, though someday
that'll likely be the case.
Also, catalog support is only available for a few processors
(currently xt and saxon), though that may change when Norm releases
his new catalog classes.
> > Without such a scheme, the xsl stylesheets can't really depend on
> > anything. To me, that would be the number one priority.
>
> If we can agree on the semantics and the name, I can propose such a
> scheme to debian-policy.
Your call as to where to go from here...
>
> > In conjunction, all the sources for the lib* packages in the above
> > directory probably need to be recompiled before being packaged. I
> > dunno--does java-policy require that? Maybe Holger could look into
> > that, as well. I don't have time right now. I also have to fix some
> > licensing issues in the *catalog* packages.
> >
> > BTW, those lib* packages are key to having a working docbook xml
> > system for debian: they provide xslt processsing with catalog
> > support. I have source packages for all of them.
>
> I'm confused and don't know anything about this.
They're java packages, distributed as compiled classes. I was trying
to ask whether the classes need to be recompiled before they get
packaged.
>
> If you want my help uploading, I'm most interested in getting the
> Docbook extension packages in
OK, I'll get them all ready to go, so at least someone can upload them.
I'll hold off on the /usr/share/sgml/ parts though, so the postinst
doesn't choke on the update-catalog part. Does that sound OK?
Mark
> --
> .....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: