Re: packaging policy questions re new standard
Well, I actually was only referring to versioned directories.
I completely agree with you. Actually I hadn't thought about it in
the way you describe it, and it indeed doesn't make sense.
We then only have to make sure we keep DTDs and stylesheets in sync,
but I consider that a part of keeping the toolchain working.
So, we deviate from the LSB in two points:
- allowing both versioned and unversioned directories
- no minor version numbering in the package name
Thanks,
Ardo
Adam Di Carlo (adam@onshore.com) wrote:
> Ardo van Rangelrooij <ardo@debian.org> writes:
>
> > Yes, as far as I'm concerned we're to use the recommended versioning
> > scheme with all the advantages of multiple version installed at the
> > same time you mentioned. Also we're supporting your hybrid setup for
> > packages where it makes more (practical) sense to do so. Versioning
> > is fine, but if it becomes a hassle then by all means don't use it.
> > This I leave to the judgement of the package maintainers. If in the
> > future it makes us incompatible wit other distro's (and the LSB)
> > then we can always drop it and allow only versioned directories.
> > We're only at the beginning of the new setup and I don't mind playing
> > around with both schemes to see how things work out.
>
> 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 can understand, say, a version of docbook DTDs for major versions,
> such a 3.x, 4.x, etc. I cannot see why it makes sense for
> docbook-xsl-stylesheets. So what, there are different bugs in
> different versions. This stuff isn't very stable yet! Is that any
> good reason to promote the endless bloat of one package for every
> minor version of a package? Users can put packages on hold if they
> want to stick with a particular version.
>
> It seems like that notion is contrary to the Debian way. I defy you
> to point to *one* other package in debian which has a new version for
> every minor update of the software. There isn't any.
>
> I beg you to keep in mind how difficult it is to actually remove
> packges from Debian. Suppose you decide that 1.40 is a really good
> stable version, and that use of the older 1.29 version is no longer
> needed. So you want the archive maintainer to delete the old
> versions. Fine -- but there are 11 of them by now. And it takes
> around a year for the archive maintainers to get to that. By then,
> there are 40 versions or more.
>
> 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?
>
> I really feel strongly about the stupidity of this. 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.
>
> > 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.
>
> This is precisely why we shoudln't have another packge name for every
> minor version.
>
> To restate -- I am *not* against versioning for major verisons, such
> as the docbook DTD 3.1, 4.0, 4.1, or something. This makes good
> compatability sense. But to do that for the stylesheets, when poeple
> aren't addressing stylesheet FPIs directly with versions, makes little
> to no sense. Perl 5.006, perl 5.005, is another example. But we
> don't have versioned perl directories for every minor release
> (5.005_03, etc).
>
> That doesn't mean we couldn't have the versioned
> /usr/share/sgml/... directory however, and a symlink to that. It jsut
> means there would only be 1 installed at any given time.
>
> People may object:
>
> Well, verison 1.29 works for document X, and 1.30 works for
> document Y, so I need both.
>
> I would counter that this means the upstream version is unstable and
> buggy and people should work with the upstream maintaint to get the
> software to be more robust.
>
> Consider another problem. Suppoes you find a bug in your maintainer
> scripts which has been around for a while. Suddenly you'll have to
> fix and re-upload X differernt copies of docbook-xsl-stylesheets!
>
> --
> .....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
>
--
Ardo van Rangelrooij
home email: ardo@debian.org
home page: http://people.debian.org/~ardo
PGP fp: 3B 1F 21 72 00 5C 3A 73 7F 72 DF D9 90 78 47 F9
Reply to: