Adam Di Carlo writes: > As I said before, I don't mind versioned directories, but I object to > versioning the packages -- at least, one package for every minor > version seems idiotic. >
I've been thinking about this issue quite a bit lately, and I have to say that I very much agree with Adam on the question of package versioning. The reason I brought these issues up in the first place was to make clear (mainly to myself) the implications of a full implementation of the lsb spec. Despite my misgivings about many aspects of the spec, I was trying my best to objectively consider its implementation. In fact, I'd even go a step further than Adam and say that we ditch the recommended top-level directory structure under /usr/share/sgml/docbook/ Recall that the spec suggests that the directory structure becomes totally flat at that point: /usr/share/sgml/docbook/ sgml-dtd-3.1/ sgml-dtd-4.1/ xml-dtd-4.1/ dsssl-stylesheets-1.62/ xsl-stylesheets-1.29/ which is not only very non-debian, but it will also become VERY ugly when the docbook subdirectory starts filling up. To me, this strucure is also idiotic, but at least it's workable. One question that's been nagging me through all of this: Why doesn't the spec reflect any features of the debian setup? Aren't specifications of this sort supposed to reflect what is successful in practice? Even a cursory glance at the number of problem-related user posts to the sgml lists (docbook-apps, docbook, debian-sgml, docbook-tools-discuss) shows very few problems with debian as compared to other linux distributions. (See this thread for an extended discussion: http://sources.redhat.com/ml/docbook-tools-discuss/2000/msg00202.html) Yet the directory structure in the specification bears almost no relationship to that of debian. It's as if debian was not even part of the discussion when it was being developed. I don't get it. My feeling is that debian-sgml ought to re-open the discussion of the spec with its developers, preferably before it gains wide acceptance thereby becoming difficult to change in any significant way. Here's my suggestion for something more sensible, similar to the current structure, with modifications in the direction of the spec. Put the main docbook (tei, etc.) dtds in versioned directories at the top of their respective subdirectories, and extensions/customizations below those. Something like this: /usr/share/sgml/docbook/ dtd/ sgml/ 3.1/ 4.1/ xml/ 3.1.7/ 4.1/ simple/ (versioned subdirs, so XML SYSids will never break) jrefentry/ 1.0/ website/ 1.6/ 1.9/ slides/ 1.0/ 1.1/ stylesheet/ dsssl/ nwalsh/ (flat distribution tree here*) cygnus/ gnome/ xsl/ nwalsh/ (flat distribution tree here*) website/ slides/ *NOTE: By "flat distribution tree, I mean the flat tree that Norm distributes. For the DSSSL stylesheets it looks like: common/ html/ images/ lib/ olink/ print/ With the addition of dsssl website stylesheets, it would look like this: common/ html/ images/ lib/ olink/ print/ website/ This stylesheet structure has the benefit of being consistent with the dtd structure above it in the sense that: stylesheets for customizations/extensions would be placed in subdirectories of stylesheets for the the main dtd Sounds like we need written policy for all this... Anyway, for completeness I also comment on Adam's statements below. > It seems like that notion is contrary to the Debian way. Strongly agree. > I ask again: do we really want docbook-xls-stylesheets-1.29, > docbook-xls-stylesheets-1.30, docbook-xls-stylesheets-1.31, > docbook-xls-stylesheets-1.32, docbook-xls-stylesheets-1.33 in Debian? > Not necessarily. I wanted to make clear some of the unforeseen implications of this spec. > I really feel strongly about the stupidity of this. So do I. > If you guys > *still* think we need to do this (versioned packages for every minor > update), we need to get archive maitnainer approval since they may > reject the scheme. > Ditch it. Leave it to the stylesheet maintainer to decide what the best-case stylesheet version is. Users can always intall them in their home directories, it's simple. (It'd be even easier of Norm wouldn't but hrefs like "n:/share/docbook/..." in the stylesheets.:-) > > About the upgrades, that' a good question. To be honest I've no idea > > whether that's useful. I can imagine that users don't care about what > > version they're running as long as it works, but I've no idea that's > > what docbook users do as normal practice. This is probably also one > > of those things we're to see how it works out. > Norm usually adds functionality to new stylesheets releases. The case of breaking XT compatibility was inevitable and necessary. And it's likely to happen again until the XSLT rec reaches the point where processor-specific extensions are no longer as attractive. For example, Norm may have to (wisely) ditch Saxon support in the future if an XSLT processor appears that blows it away. But we can simply deal with these things on a case-by-case basis, they're not gonna happen that frequently. I believe we're all on the same page here. What'd be nice: a page that showing the present status of our policy agreements/disagreements on what goes where, packaging issues, etc... my $0.02 Mark P.S. my maintainership ought to go through in a day or two.
