launchpad-users team mailing list archive
Mailing list archive
Re: Version older than that in the archive
On Wed, Nov 25, 2020 at 10:43:18AM -0500, Pierre Abbat wrote:
> On Wednesday, November 25, 2020 10:24:05 AM EST Colin Watson wrote:
> > For this time, you'll have to manually remove 0.5.1rc3-3 first, after
> > which you should be able to upload 0.5.1-1. However, any systems that
> > have the old version installed won't automatically upgrade to the new
> > version, because 0.5.1rc3-3 < 0.5.1-1 in dpkg's version ordering. If
> > that's important to you, then you'll need to work around that somehow.
> > I might be inclined to artificially change the version to something like
> > 0.5.1+0-1 instead, which actually is greater than 0.5.1rc3-3 and
> > shouldn't risk confusion with future upstream releases, but it may
> > depend slightly on your relationship with upstream.
> This is my testing repo; release candidates don't go in my release repo (which
> is still empty, as I'm still learning how to package and need someone to test
> it). Do I have to wait six hours before uploading 0.5.1?
No, it should work immediately after you remove the greater version.
> > For next time, 0.5.1rc3-3 should have been spelled 0.5.1~rc3-3 instead,
> > and then the ordering would work properly.
> Does this ordering hold in pkg, pkgsrc, and other package managers? Should I
> number release candidates that way when I tag them?
Package managers tend to have their own version comparison rules, so no.
dpkg's scheme works in practice with most reasonable upstream versioning
schemes (that was among its design criteria), but pre-releases are
always a bit of a difficulty with any scheme.
It's accepted practice in Debian and its derivatives to mangle the
upstream version as needed to fit into dpkg ordering; while this is
rarely needed, it's better than version ordering being interpreted
wrongly. See for example the various "versionmangle"-related options in
uscan(1), or you can just rename tarballs and adjust debian/changelog
header lines manually if you prefer.
For more details than you probably wanted to know about the version
comparison rules, see here (from "When comparing two version numbers"
Colin Watson (he/him) [cjwatson@xxxxxxxxxxxxx]