[Distutils] SOLVED: bdist_rpm and pre-release python packages / eggs (was: pre-release versioning problems with sdist, bdist_rpm, bdist_debian)

[Gerry Reno]

Manuel Amador (Rudd-O) wrote:
> 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 
form or the dot form within the 'release'.  You could not mix them.  And 
then either form would work just fine.

> 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 
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 at rudd-o.com>
> 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?
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-python-devel-list/attachments/20090311/09a57f30/attachment.htm>