Adam Di Carlo writes: > Mark Johnson <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]<URL:http://www.onShore.com/>
