Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for June 20, 2013
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
The original announcement answers your question:
support for dpkg-style tilde operator
RPM 4.10 released
Posted May 25, 2012 9:09 UTC (Fri) by nim-nim (subscriber, #34454)
So it's just a compatibility feature.
Posted May 25, 2012 9:20 UTC (Fri) by jengelh (subscriber, #33263)
Since when did upstream ever ask distributions about how they should be numbering their releases?
Posted May 25, 2012 11:09 UTC (Fri) by misc (subscriber, #73730)
And what nimnim say about numbering release is about the release tag of rpm, ie the practice of using 0.beta1.1 for a beta1 rpm, instead of using 1.
Posted May 27, 2012 3:14 UTC (Sun) by drag (subscriber, #31333)
Any person who sees Foo, version 1.3 and then Foo, version 1.3.2 would think that 'ah-hah' they must if released a bug fix version or something! Since, you know, 2 is a higher number then nothing which in human idioms is usually simultaneous with zero..
To me this seems very similar to trying to work around kernel bugs in userspace. Although in this case the bug is introduced into the metadata by upstream rather then program logic.
Posted May 25, 2012 14:04 UTC (Fri) by gioele (subscriber, #61675)
> Since when did upstream ever ask distributions about how they should be numbering their releases?
Upstream can also actively ignore distributions' best practices. For example LibreOffice uses 18.104.22.168 to identify 3.3.4-rc2.  A naive comparator will tell you that 22.214.171.124 (actually 3.3.4-rc2 pre-release) is newer than 3.3.4 (the final version).
Posted May 28, 2012 12:48 UTC (Mon) by nix (subscriber, #2304)
Posted May 25, 2012 11:07 UTC (Fri) by jordi (subscriber, #14325)
What happens in Red Hat when upstream releases package_2.6.2rc3? Do you invent 126.96.36.199.3? 2.6.1+2.6.2rc3? Do you just package 2.6.2rc3 and "I'll deal with the final release version number later"?
The tilde feature is *very* useful for RPM, regardless of what you think of Debian.
Posted May 25, 2012 11:22 UTC (Fri) by nim-nim (subscriber, #34454)
(which is actually cleaner since it does not depend on upstream choosing ordered tags for its pre-release names)
Did you really think Fedora needed Debian help to handle beta version packaging?
Posted May 25, 2012 13:51 UTC (Fri) by jond (subscriber, #37669)
Posted May 25, 2012 14:09 UTC (Fri) by BenHutchings (subscriber, #37955)
Posted May 25, 2012 14:24 UTC (Fri) by jordi (subscriber, #14325)
For ALSA, we had this: alsa-lib (1.0.9+1.0.10rc3-1), which isn't pretty either.
Posted May 25, 2012 17:00 UTC (Fri) by nim-nim (subscriber, #34454)
If you wanted to display the upstream version as-is in packages you'd need to record two separate versions (the upstream version and the internal package version) except if you then started to display the upstream version as desired by some upstreams suddenly the package update rules would make no sense and become unpredictable to the user (which the disto is supposed to help control his system).
Upstreams that do not like those workarounds just have to reserve real numbers for their beta versions and every sane package manager will use them as-is.
Posted May 25, 2012 23:34 UTC (Fri) by vonbrand (subscriber, #4458)
Pray tell what is wrong with RPMs <version>-<release> tagging, where the version is uptream and release is local. So I have kernel-3.3.6-3.fc16.x86_64 on Fedora 16 (i.e., upstream 3.3.6, Fedora's release 3 for Fedora 16 on x86_64). On rawhide I've got kernel-3.5.0-0.rc0.git6.1.fc18.x86_64 (upstream 3.5.0 to-be, locally 0.rc0.git6.1). No need for magic marker characters at all.
Posted May 27, 2012 10:29 UTC (Sun) by jamesh (guest, #1159)
If you have a "3.5.0-0.rc0.git6.1.fc18" package that isn't actually based on the upstream 3.5.0 release (which it wouldn't, since there are only release candidates available), then you aren't following those guidelines.
Posted May 27, 2012 16:27 UTC (Sun) by rahulsundaram (subscriber, #21946)
Posted May 28, 2012 2:55 UTC (Mon) by jamesh (guest, #1159)
Both the Fedora versioning guidelines and the Debian use of '~' are attempts to handle upstream releases or snapshots whose version numbers didn't match the package manager's rules.
My point is that if you've got a part of the package name that is nominally "the version of the upstream release", then it seems cleaner to identify what upstream release you're using in that field rather than spilling over into the release part.
Posted May 28, 2012 3:44 UTC (Mon) by rahulsundaram (subscriber, #21946)
Posted May 28, 2012 8:31 UTC (Mon) by jamesh (guest, #1159)
When you push out a new RPM package, there is a single file source package that won't conflict with the old package in the archive. Debian source packages generally come as three files: one representing the pristine source, one representing the packaging, and one holding metadata. If you push two package versions to the archive built from the same pristine source, then they will share the first of those files.
This is generally a good thing, since it reduces the size of the archive and reduces the traffic needed to mirror the archive. It would cause problems if you published packages for a release candidate and final version using the same value in the "upstream version" part of the package version number.
Now even though these technical considerations don't affect you, hopefully you'll consider using it in cases where it makes the package version numbers easier to understand.
Posted May 28, 2012 9:09 UTC (Mon) by nim-nim (subscriber, #34454)
Using an ascii ordering quirk that makes tilde lesser than zero is easier to understand that using zero as lesser than any positive number?
Posted May 28, 2012 10:30 UTC (Mon) by Jonno (subscriber, #49613)
Posted May 28, 2012 11:42 UTC (Mon) by vonbrand (subscriber, #4458)
All this mess because Debian users are considered morons, unable to parse 2.3.4-0.rc5 as before 2.3.4-1; while they are instantly in position to understand that 2.3.4~2 comes before 2.3.4-1. All justified because somebody somewhen could perhaps reuse the same source file.
Paint me totally unimpressed by this "technical" advantage.
Posted May 28, 2012 14:29 UTC (Mon) by foom (subscriber, #14868)
Posted May 28, 2012 23:45 UTC (Mon) by drag (subscriber, #31333)
It's the internet. It is what it is.
Posted May 28, 2012 14:48 UTC (Mon) by jamesh (guest, #1159)
Well, I described a technical reason for the Debian behaviour in a parent post.
If I have a foo_2.3.4-0.rc5 package, its corresponding source package would consist of the files:
If I have a foo_2.3.4-1 package, its corresponding source package would consist of the following files:
If the two packages were built off of different pristine source tarballs, then they could not co-exist in the same package archive since they depend on different contents for foo_2.3.4.orig.tar.gz.
The fact you only need a single copy of the pristine source is great when the packages really are based off of the same tarball, but it can't handle this kind of case. For that, you need some way to represent "a version that sorts just before 2.3.4" in the upstream version component of the package version number.
Posted May 28, 2012 20:07 UTC (Mon) by nim-nim (subscriber, #34454)
Now really the pre-version is put at the end of the rpm package version because that's the last element to sort when comparing packages (name-epoch-version-release), I suppose it could be made explicit with a new metadata field for informational version strings (sorted after name, epoch, software version, package release), but few people seem to miss it right now
Posted May 25, 2012 15:18 UTC (Fri) by branden (subscriber, #7029)
Posted May 25, 2012 15:46 UTC (Fri) by rahulsundaram (subscriber, #21946)
On a side note, RPM features and Fedora policies are different from each other. There are a number of RPM features Fedora simply does not use or recommend at all.
Posted May 25, 2012 16:21 UTC (Fri) by branden (subscriber, #7029)
Posted May 26, 2012 6:19 UTC (Sat) by carlm (guest, #84710)
Posted May 26, 2012 6:22 UTC (Sat) by branden (subscriber, #7029)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds