Re: packaging policy questions re new standard
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.
Reply to: