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

[Manuel Amador (Rudd-O)]

Gerry,

What you have said is interesting.  Note that you're using underscores in the 
release number (against F packaging policy), and the general scheme for 
devising the release number is also against Fedora packaging policy too (which 
is highly likely to cause problems in RHEL down the road too).  Sure, it works 
too, but it'd be good if we could stick to the published policies which are 
also known to work and everybody adheres to them already.


> 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


-- 

	Manuel Amador (Rudd-O) <rudd-o at rudd-o.com>
	Rudd-O.com - http://rudd-o.com/
	GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/

Reality always seems harsher in the early morning.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-python-devel-list/attachments/20090311/b40d9906/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-python-devel-list/attachments/20090311/b40d9906/attachment.sig>