[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

dpkg and pre-versions

Many packages have pre-versions, including the Linux kernel itself.  We've
all been told epochs aren't for handling them and that we should mutilate
the version numbers so they fit dpkg's needs.  Our package manager is not,
unfortunately, an AI.  =)

One of the ways to package a pre-version that is no longer available is to
package 1.2.3pre1 as 1.2.3-0pre1.1, which arguably was never a good
solution.  (It tended to play hell with other archs, but it was the most
readable so it got used anyway..)  Katie now rejects attempts to do this
because of changes to the orig.tar.gz, which is probably a good thing.

A discussion came up two years ago about this and people decided that dpkg
should learn to recognize something as always sorting lower than if it
wasn't there (the opposite of an epoch).  Of course, at the time dpkg
didn't exactly have full-time maintenance, so everyone seemed to agree
that it would be nice and there the issue died.  The code's not complex
and I've begun adding support for a clean pre-version to the code.  What's
missing is a character to use to delimit pre-versions.

So far, the only suggestion I've been given is !.  No, it's not a good
choice, but it's the only constructive suggestion I've been given, so for
the sake of an example I'll use it.  If you wanted to 1.2.3pre2 of foo,
you would package it as 1.2.3!pre2-1 rather than 1.2.3pre2-1 or
1.2.2+1.2.3-1 or or 1.2.3-0pre2.1 or any of the other weird
half-assed things people tend to come up with for this.  Everything to the
right of the ! and before the last - would be treated as the package's
pre-version, with a pre-version of 0 (ie, not there) being treated as
always greater.

Currently dpkg parses a version first, breaking it up into managable
pieces: epoch, version, revision.  It compares the epochs, then if
necessary the version, then the revision.  The latter two use a function
to do the dirty work and with exception of the case where only one (or no)
pre-version exists, the same function would apply to pre-version
comparisons, which would be done before the revision.  The parser's a
little more work, but the code to figure out where the revision starts is
there and if the character used to denote a pre-version is not currently
used, it isn't difficult to modify the parser.

So yeah, it would be nice.  Except nobody else did it.  I'm tired of
arguing about whether or not it's strictly necessary.  There are other
options, but none of them really work in all cases (or even most cases)
and come down to mutilating our package's versions to satisfy a problem
we've known about for a long time now.  If nobody else wants to fix it, I
will (and have already got the the compare code finished..)  Now it's time
to modify the parser, what character do I use?  The bang's used by the
shell, so it's pretty much out.  % was suggested, but it has problems too.
Any others?

Joseph Carter <knghtbrd@debian.org>                Free software developer

I would rather spend 10 hours reading someone else's source code than 10
minutes listening to Musak waiting for technical support which isn't.
        -- Dr. Greg Wettstein, Roger Maris Cancer Center

Attachment: pgpAdruOu_djR.pgp
Description: PGP signature

Reply to: