Manuel Amador (Rudd-O) wrote:
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
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
1.2dev: version 1.2 release 0.0.0dev REGARDLESS of user-specified
1.2dev-r56: version 1.2 release 0.0.56devr REGARDLESS of user-specified
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
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
yum.rudd-o.com subdir SCRIPTS, it is documented step by step, but this
should really be integrated within the setuptools bdist_rpm kludge.
I am exhausted.
Let me share with you what we had implemented and the POLICY that we
put in place with regards to VERSION-RELEASE strings. We did not look
at this from egg standpoint as we just distribute RPMS.
I sent this to Tarek a while ago:
What I had implemented seems to have the VERSION-RELEASE string issue
solved using a 'workaround' and a manual policy for the moment. It
would of course be
better if distutils just did this automatically but this is at least
working. Tarballs, rpms have the same designations and all the lexical
ordering is correct so that even for pre-release versioning the rpms
update each other correctly.
What I did was in setup.py added:
version = '5.0.0'
release = '0_rc3_00001681'
if sys.argv != 'bdist_rpm':
version = version + '-' + release
In setup.cfg added:
# release must exactly match 'release' as set in setup.py
# END WORKAROUND
And then I setup the following policy regarding VERSION-RELEASE naming:
(this example uses bzr as source code control system but you can
svn, rcs, or any other type of sccs)
release="0_00012345" (where 00012345 is the
revision number from bzr in ZERO-PADDED FIELD OF 8)
Release Candidate code:
Release Candidate code fix:
Final Release code:
Notice that lexical ordering is proper in all cases. Even where the
alpha, beta, rc releases may be followed by a bzr fix revision.
The ensures that both tarballs and packages such as rpm will contain
the same VERSION-RELEASE designations.
Also, the use of UNDERSCORES in the 'release' string assures that there
is no ambiguity with regard to parsing VERSION-RELEASE string
combination or full package names which have hyphens in specific