<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Manuel Amador (Rudd-O) wrote: <blockquote cite="mid200903110921.48576.rudd-o@rudd-o.com" type="cite"> <meta name="qrichtext" content="1"> <style type="text/css">p, li { white-space: pre-wrap; }</style>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 yum.rudd-o.com subdir SCRIPTS, it is documented step by step, but this should really be integrated within the setuptools bdist_rpm kludge. Really. I am exhausted. </blockquote> Hi Manuel, 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. #WORKAROUND: What I did was in setup.py added: ======================== version = '5.0.0' release = '0_rc3_00001681' if sys.argv[1] != 'bdist_rpm': version = version + '-' + release ======================== In setup.cfg added: ======================== [bdist_rpm] # release must exactly match 'release' as set in setup.py release=0_rc3_00001681 ================== # 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 substitute svn, rcs, or any other type of sccs) Development code: version="5.0.0" release="0_00012345" (where 00012345 is the revision number from bzr in ZERO-PADDED FIELD OF 8) tarball: foo-5.0.0-0_00012345.tar.gz rpm: foo-5.0.0-0_00012345.noarch.rpm Alpha code: version="5.0.0" release="0_alpha1_00123456" tarball: foo-5.0.0-0_alpha1_00123456.tar.gz rpm: foo-5.0.0-0_alpha1_00123456.noarch.rpm Beta code: version="5.0.0" release="0_beta1_00234567" tarball: foo-5.0.0-0_beta1_00234567.tar.gz rpm: foo-5.0.0-0_beta1_00234567.noarch.rpm Release Candidate code: version="5.0.0" release="0_rc1" tarball: foo-5.0.0-0_rc1.tar.gz rpm: foo-5.0.0-0_rc1.noarch.rpm Release Candidate code fix: version="5.0.0" release="0_rc1_00345678" tarball: foo-5.0.0-0_rc1_00345678.tar.gz rpm: foo-5.0.0-0_rc1_00345678.noarch.rpm Final Release code: version="5.0.0" release="1" tarball: foo-5.0.0-1.tar.gz rpm: foo-5.0.0-1.noarch.rpm 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 positions. Regards, Gerry </body> </html>