Description of problem:

Building pre-release python distutils packages with python setup.py
bdist_rpm
works, but the version number is "RPM-higher" than the official release
package
that is released later.

This constitutes a problem because many of the components in major
Python apps
like Zope -- distributed as cheese shop eggs and downloadable via pip or
buildout -- are pre-release packages which, when turned into RPMs, contain
RPM-invalid version numbers.  The RPMs build, but the pre-release
packages are
considered "newer" by yum, so you can imagine the havoc that breaks.

How reproducible:

always


Steps to Reproduce:
1. python setup.py bdist_rpm
2. inspect version / release number of resulting RPMs, find out it's wrong
3. do not profit!

Actual results:

distutils package version: 1.4a
rpm package version: 1.4a


Expected results:

http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Non-Numeric_Version_in_Release

Additional info:

patch attached.  works against python 2.4, may apply fine to python 2.5
or 2.6
too since distutils hasn't undergone that big of a rewrite.  

Ojo: the patch has been tested with distutils AND setuptools.

Heads up: The fix requires a patch (distributed with the python 2.4.x
RPM in CentOS) to be applied first.  I am attaching said patch so you
can apply the fix.

the newest svnversions patch is to handle the case of people who want to
build svn checkouts (usually versionnumbered by dev or dev-rXXXYYZZ). 
it overrides the release to be zero so they never upgrade alpha, beta
packages.

A better patch

This patch autodetects dependencies based on the earlier patch and egg
metadata, if setuptools is importable.

brown paper bug in the last lexic patch

FYI:

http://rudd-o.com/new-projects/python-improvements

I am considering some changes in the auto-dependency part of the patch.
 Keep tuned.

Please write your patches against the trunk. I'll start to look at them
after Pycon. Regards

about python trunk...

gimme some time to port them incrementally to all popular stable pythons
first, then to trunk.  will be glad to do this.

Now, by trunk, do you mean python 3.x?

With the new Mercurial repositories and adapted workflow, patches should apply to a clone of the 3.1 branch.

If you could also remove outdated or superseded patches from this issue (or give their names if you can’t remove them), it would help reviewing.  Thanks in advance.

Given the age of this, the status of distutils and the existence of py2rpm, I am closing it.