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

[Gerry Reno]

Gerry Reno wrote:
> Manuel Amador (Rudd-O) wrote:
>> 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.
>>
>>
> Manuel,
>   Are you on the FPP committee?  I looked at the fedora packaging 
> policy and it is rather similar except it has periods where we have 
> underscores.  It would be nice if fedora could expand the policy to 
> allow the underscore style as well.  Both approaches work just as 
> well.  And to me the underscore form is a lot more readable.
>   Also, there isn't a lot of examples in the FPP regarding adding the 
> vcs revision number into the release string.  I like the way we do it 
> because it's lexically correct always.  Maybe this could be added to FPP?
>
>
Manuel,
  Also examples in the fedora packaging policy don't even make sense.  
It's no wonder no one every gets this right.

alsa-lib-0.9.2-0.1.beta1 (add a new patch on top of 0.9.2beta1)
alsa-lib-0.9.2-0.2.beta1 (upgrade to 0.9.2beta2)
alsa-lib-0.9.2-0.3.beta2 (upgrade to 0.9.2beta3)
^^^^^^^^^^^^^^^^^^And this ridiculous construction is from the 
Department of Redundancy Department

This would be far better and make a lot more sense like:
alsa-lib-0.9.2-0_beta1_00001727   # where 1727 is the vcs revision, 
using numbers like patch 1 is absolutely meanless to most people, they 
want to know what tagged release (beta1 tag) and then what revision 
contains the update patches.
OR
alsa-lib-0.9.2-0_beta1_p0               # where p0 means patch 0


Regards,
Gerry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-python-devel-list/attachments/20090311/ddd47958/attachment.htm>