My solution tackles it from another direction, using observed egg packaging practices. This is what I have observed in setup.pys, and eggs' requires.txts so far:

1.2dev: refers to unspecified not-even-alpha quality checkout or source drop
1.2dev-r5667: refers to the checkout of revision 5667, not-even-alpha
1.2a1: refers to Alpha 1 of intended version 1.2
1.2a2: refers to Alpha 2 of intended version 1.2
1.2b1: refers to Beta 1 of intended version 1.2
1.2: refers to official 1.2 release

Note NO UNDERSCORES. In order to satisfy the fedora package naming guidelines and RPM's lexicographical sort, this is what happens within my patches:

1.2dev: version 1.2 release 0.0.0dev REGARDLESS of user-specified release
1.2dev-r56: version 1.2 release 0.0.56devr REGARDLESS of user-specified rel
1.2a1: version 1.2 release 0.<user-specified release>.a1
1.2a2: version 1.2 release 0.<user-specified release>.a2
1.2b1: version 1.2 release 0.<user-specified release>.b1
(note in the last three it is the responsibility of the builder to bump the <release> manually, there is really nothing we can do about it)
1.2: version 1.2 release <user-specified release>

In this manner we can accurately map existing practice (what people are actually DOING at least in a significant amount of eggs -- the plone ones) in python egg versioning numbers to RPM lexicographical sort in a manner that lets package managers "do the right thing".

Also, we need a standard way of trolling the requires.txt for the egg dependencies and transforming them into RPM dependencies, otherwise your RPMs won't work in concert. Code for that in my workbench subdir SCRIPTS, it is documented step by step, but this should really be integrated within the setuptools bdist_rpm kludge. Really.

I am exhausted.

El Miércoles 11 Marzo 2009, Gerry Reno escribió:
> Manuel Amador (Rudd-O) wrote:
> > Hello, guys,
> >
> >
> > I have fixed distutils (and setuptools remains working) with the
> > attached patch. Now, RPMs will be built according to the Fedora
> > Package Naming Guidelines:
> >
> >
> >
> >ion_in_Release
> >
> >
> > which I understand to be the most useful reference in terms of naming
> > pre-release packages. This should work correctly in at least:
> >
> >
> > - Fedora
> > - RHEL
> > - SUSE
> >
> >
> > I urge you patch your python 2.4s and 2.5s and 2.6s and push this
> > update to distributions. I have done that myself at my own repository.
> >
> >
> > Now we can enjoy one more reason to build RPMs (and eggs! ...
> > according to my workbench at -- feel
> > free to pick its brains) DIRECTLY from the cheese shop, especially if
> > you're using pip.
> >
> >
> > Oh, I also have pip at my repo (cd ../RPMS/noarch in my workbench).
> >
> >
> > See attached patch. I will log bugs where it corresponds too.
> > --
> >
> >
> > Manuel Amador (Rudd-O) <>
> > -
> > GPG key ID 0xC8D28B92 at
> >
> >
> > Now playing, courtesy of Amarok: Aqua - Cartoon heroes
> > Windows 95 is not a virus. Viruses actually do something.
> Hi Manuel,
> You worked on my problem! Great.
> So today what we have been doing to deal with the pre-release and
> lexical ordering problem involving pre-releases is this:
> We impose a restriction on how the pre-release is identified. So
> for example if you intend to end up with a final version-release of
> 5.0.0-1 and you want to first put out some betas or release candidates
> then we have to name them as, 5.0.0-0_beta1, or 5.0.0-0_rc1 and this is
> so that the lexical ordering for RPM will be correct. In other words
> you must put the pre-release designation into the 'release' part of
> VERSION-RELEASE. What we had seen developers doing previously was to
> name these as 5.0.0_beta1 or 5.0.0_rc1 (making the pre-release
> designation part of the 'version' string) which then did not work for
> the lexical ordering of the final release of 5.0.0-1 because 5.0.0
> (version) was not lexically superior to 5.0.0_rc1. So we were able to
> solve this problem without any code changes to distutils. But this also
> presented a challenge for the other distribution targets such as 'sdist'
> because they were totally unaware of this 'version-release' combination
> and only knew about 'version'. So as a workaround we were doing this:
> # define both version AND release
> version='5.0.0'
> release='1'
> # combine them for all targets except 'bdist_rpm'
> if sys.argv[1] != 'bdist_rpm':
> version = version+'-'+release
> So this wasn't perfect but it actually worked quite well and we could
> get 'sdist' to work properly in conjunction with 'bdist_rpm'.
> So now with your patch all the targets should be able to set and use
> both 'version' and 'release' and we don't need our workaround and that
> will be great.
> Regards,
> Gerry


Manuel Amador (Rudd-O) <> -
GPG key ID 0xC8D28B92 at

Example is not the main thing in influencing others. It is the only thing.
-- Albert Schweitzer