[Distutils] SOLVED: bdist_rpm and pre-release python packages / eggs (was: pre-release versioning problems with sdist, bdist_rpm, bdist_debian)

[Gerry Reno]

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. 
> Really.
>
>
> I am exhausted.
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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090311/10625992/attachment-0001.htm>