| |||||||||||||
RPM 4.10 releasedRPM 4.10 releasedPosted May 25, 2012 11:07 UTC (Fri) by jordi (subscriber, #14325)In reply to: RPM 4.10 released by nim-nim Parent article: RPM 4.10 released
Yeah, because Debian added this feature out of boredom, right?
What happens in Red Hat when upstream releases package_2.6.2rc3? Do you invent 2.6.1.90.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.
(Log in to post comments)
RPM 4.10 released Posted May 25, 2012 11:22 UTC (Fri) by nim-nim (subscriber, #34454) [Link]
As misc wrote pre-versions are handled fine in rpm by using 0.index.whateverupstreamcallsit in the release tag
https://fedoraproject.org/wiki/Packaging:NamingGuidelines...
(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?
RPM 4.10 released Posted May 25, 2012 13:51 UTC (Fri) by jond (subscriber, #37669) [Link]
There's a real you-versus-us sentiment in this thread, which strikes me as entirely counter-productive.
RPM 4.10 released Posted May 25, 2012 14:09 UTC (Fri) by BenHutchings (subscriber, #37955) [Link]
So although it's part of the upstream version, you put it in the package release as if it was just a packaging difference? Seems like a workaround to me.
RPM 4.10 released Posted May 25, 2012 14:24 UTC (Fri) by jordi (subscriber, #14325) [Link]
Absolutely. This looks as horrible as 1.0.25really1.0.24-1 that we seen from time to time in our archive. :)
For ALSA, we had this: alsa-lib (1.0.9+1.0.10rc3-1), which isn't pretty either.
RPM 4.10 released Posted May 25, 2012 17:00 UTC (Fri) by nim-nim (subscriber, #34454) [Link]
Pre-releases can only be handled by workarounds since they are outside normal version numbering and many upstreams do not even use ordered pre-release tags. There is no way any automated process can handle the conflicting pre-release conventions that exist out there, so you'll need to normalize the numbering one way or another (and ~ is just another uglier way to do it).
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.
RPM 4.10 released Posted May 25, 2012 23:34 UTC (Fri) by vonbrand (subscriber, #4458) [Link] 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.
RPM 4.10 released Posted May 27, 2012 10:29 UTC (Sun) by jamesh (guest, #1159) [Link]
Well, according to the RPM documentation, the <version> part is intended to be the upstream version number, and the <release> part is a version number for the packaging.
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.
RPM 4.10 released Posted May 27, 2012 16:27 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
Fedora packaging follows Fedora packaging guidelines which are easily accessible. How RPM is used has evolved over time. If you are awaren't aware of that, you would see conflict in such instances.
RPM 4.10 released Posted May 28, 2012 2:55 UTC (Mon) by jamesh (guest, #1159) [Link]
I realise that the Fedora guidelines have changed over time.
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.
RPM 4.10 released Posted May 28, 2012 3:44 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
I have no strong opinions on that. Both is functional.
RPM 4.10 released Posted May 28, 2012 8:31 UTC (Mon) by jamesh (guest, #1159) [Link]
I guess the reason Debian folk feel so strongly about it is that it actually has technical merits rather than aesthetic or philosophical ones.
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.
RPM 4.10 released Posted May 28, 2012 9:09 UTC (Mon) by nim-nim (subscriber, #34454) [Link]
????
Using an ascii ordering quirk that makes tilde lesser than zero is easier to understand that using zero as lesser than any positive number?
RPM 4.10 released Posted May 28, 2012 10:30 UTC (Mon) by Jonno (subscriber, #49613) [Link]
No, but it is easier to understand that upstream release number 1.0~rc1 is less than upstream release number 1.0, than understanding that upstream release number 1.0 is sometimes upstream release 1.0rc1 and sometimes upstream release 1.0, depending on what the packaging version is.
RPM 4.10 released Posted May 28, 2012 11:42 UTC (Mon) by vonbrand (subscriber, #4458) [Link] 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.
RPM 4.10 released Posted May 28, 2012 14:29 UTC (Mon) by foom (subscriber, #14868) [Link]
Can everyone please calm down? This seems to have degenerated into a "Deb rulez!!!" "No, RPM is the bestest!!!" argument, and it's completely ridiculous.
RPM 4.10 released Posted May 28, 2012 23:45 UTC (Mon) by drag (subscriber, #31333) [Link]
Don't worry about it. It just makes it easier to know which people to ignore.
It's the internet. It is what it is.
RPM 4.10 released Posted May 28, 2012 14:48 UTC (Mon) by jamesh (guest, #1159) [Link] 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: foo_2.3.4-0.rc5.dsc foo_2.3.4-0.rc5.diff.gz foo_2.3.4.orig.tar.gz If I have a foo_2.3.4-1 package, its corresponding source package would consist of the following files: foo_2.3.4-1.dsc foo_2.3.4-1.diff.gz foo_2.3.4.orig.tar.gz 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.
RPM 4.10 released Posted May 28, 2012 20:07 UTC (Mon) by nim-nim (subscriber, #34454) [Link]
rpm separates the upstream source file name from the package versioning (you can define the source name from package metadata, but it's not a hard link), so you don't need to play games to reuse the same files
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
RPM 4.10 released Posted May 25, 2012 15:18 UTC (Fri) by branden (subscriber, #7029) [Link]
"Did you really think Fedora needed Debian help to handle beta version packaging?"
Evidently so.
RPM 4.10 released Posted May 25, 2012 15:46 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
I am disappointed at these sort of replies. Debian and Fedora have corroborated for licensing issues and for packaging guidelines or convincing upstream to do things in a distribution friendly way on several occasions. Common ground and ability to work together is something we should be proud of. Copying ideas or even whole sale implementation is a key benefit of free software. Not something to bicker about.
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.
RPM 4.10 released Posted May 25, 2012 16:21 UTC (Fri) by branden (subscriber, #7029) [Link]
Well-said. I, too, am disappointed in nim-nim.
|
|||||||||||||