[Distutils] SOLVED: bdist_rpm and pre-release python packages / eggs (was: pre-release versioning problems with sdist, bdist_rpm, bdist_debian)
greno at verizon.net
Wed Mar 11 15:51:47 CET 2009
Manuel Amador (Rudd-O) wrote:
> 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.
> 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
substitute 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 positions.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG