Re: packaging policy questions re new standard
Can you do me a favor and send out again to me (and/or the list) the
full list of relevant URLs for the LSB spec?
Mark Johnson <mark@phy.duke.edu> writes:
> 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/
I don't know if I'd go that far.
> 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.
I don't think it's idiotic. I don't even think it's all that bad.
Anyhow, if you talk to LSB, be sure to be more diplomatic than this.
They aren't idiots -- even smart people need correcting sometimes.
> 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?
Heh. Not always. Definately a good arguing point however.
> 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.
Absolutely.
> Here's my suggestion for something more sensible, similar to the
> current structure, with modifications in the direction of the spec.
[...]
> 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/
This is somewhat reasonable. I don't feel all that strongly about,
say, not having
dtd/xml/slides-1.0
dtd/xml/slides-1.1
In fact, dtd/xml/slides-1.0 is actually closer to current Debian
practice than what you proposed.
Can you justify all this directory depth in terms of user benefit?
> 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...
Hmm, is that wise to mix up the stuff this way? Does his XSL website
stuff assume it needs to be close to XSL docbook (uses relative
referencing)?
If not, it would seem cleaner to keep the separte modules more
separated than this, and probably close to the practice, say, of poor
schlubs installing on windows boxes.
> 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.
Yes, the version juggling I'm seeing with the XSL stuff tells me the
spec isn't mature and the implementations are far far far from
mature. I can't imaging trying to remember all this. I just hope it
settles down (or we'll see a mass migration back to DSSSL, which would
be nice).
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: