1) No, I'm not on the committee. 2) The policy is similar. 3) Both approaches cannot work in parallel because the period is lexicographically distinct to the underscore No. Within a project you would have to choose, either the underscore
5) The policy has been tested and takes advantage of the already-deployed RPM code in tens of millions of machines out there. We do not know what sorts of malfunctions using underscores might cause. Yes, and there are plenty of examples of packages that don't follow the
Manuel Amador (Rudd-O) wrote: form or the dot form within the 'release'. You could not mix them. And then either form would work just fine. policy as well. Probably more than are actually following it.
4) The policy *does* make sense especially in the place you quoted it. The release begins with 0.1 and increments to 0.2 0.3 0.4 whenever you change the package (add patches, modify specfile) but continue to use the same source package, which is the purpose of the release tag in the first place -- to mark a new release of the SAME source package. Unfortunately, it requires that when a new beta source package (even one that is lexicographically later than the existing package) is compiled, the release must be bumped to upgrade it. My distutils packages explicitly punt this release bump to the packager so that he has control over which beta packages to push out. And the reason that the release tag always begins with 0. in nonstable releases is pretty dead simple: so that the release package with version 0.9.8-1 (the first official stable release) can be lexicographically higher and is automatically updated with package managers like yum. The policy doesn't make sense in the example I quoted if you read the comments. Look where it says upgrade to 0.9.2beta3 yet the example shows beta2. I can see that what is trying to be done is to add extra numerics just to make the numerics significant and then basically you can ignore the beta, alpha, etc. But this is more confusing than helpful and its not necessary to make things lexically ordered.
The goal is proper lexical ordering so that rpm/yum is happy and packages will upgrade correctly. And either form accomplishes this. Regards, Gerry
Guys, amirite?
Manuel, Are you on the FPP committee? I looked at the fedora packaging policy and it is rather similar except it has periods where we have underscores. It would be nice if fedora could expand the policy to allow the underscore style as well. Both approaches work just as well. And to me the underscore form is a lot more readable. Also, there isn't a lot of examples in the FPP regarding adding the vcs revision number into the release string. I like the way we do it because it's lexically correct always. Maybe this could be added to FPP?
Manuel, Also examples in the fedora packaging policy don't even make sense. It's no wonder no one every gets this right.
alsa-lib-0.9.2-0.1.beta1 (add a new patch on top of 0.9.2beta1) alsa-lib-0.9.2-0.2.beta1 (upgrade to 0.9.2beta2) alsa-lib-0.9.2-0.3.beta2 (upgrade to 0.9.2beta3) ^^^^^^^^^^^^^^^^^^And this ridiculous construction is from the Department of Redundancy Department
This would be far better and make a lot more sense like: alsa-lib-0.9.2-0_beta1_00001727 # where 1727 is the vcs revision, using numbers like patch 1 is absolutely meanless to most people, they want to know what tagged release (beta1 tag) and then what revision contains the update patches. OR alsa-lib-0.9.2-0_beta1_p0 # where p0 means patch 0
Regards, Gerry
--
Manuel Amador (Rudd-O)
Rudd-O.com - http://rudd-o.com/ GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/ If you are what you eat, does that mean Euell Gibbons really was a nut?