[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)]

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.

El Miércoles 11 Marzo 2009, Gerry Reno escribió:
> Manuel Amador (Rudd-O) wrote:
> > Hello, guys,
> >
> >
> > I have fixed distutils (and setuptools remains working) with the
> > attached patch. Now, RPMs will be built according to the Fedora
> > Package Naming Guidelines:
> >
> >
> > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Non-Numeric_Vers
> >ion_in_Release
> >
> >
> > which I understand to be the most useful reference in terms of naming
> > pre-release packages. This should work correctly in at least:
> >
> >
> > - Fedora
> > - RHEL
> > - SUSE
> >
> >
> > I urge you patch your python 2.4s and 2.5s and 2.6s and push this
> > update to distributions. I have done that myself at my own repository.
> >
> >
> > Now we can enjoy one more reason to build RPMs (and eggs! ...
> > according to my workbench at http://yum.rudd-o.com/SCRIPTS/ -- feel
> > free to pick its brains) DIRECTLY from the cheese shop, especially if
> > you're using pip.
> >
> >
> > Oh, I also have pip at my repo (cd ../RPMS/noarch in my workbench).
> >
> >
> > See attached patch. I will log bugs where it corresponds too.
> > --
> >
> >
> > 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/
> >
> >
> > Now playing, courtesy of Amarok: Aqua - Cartoon heroes
> > Windows 95 is not a virus. Viruses actually do something.
>
> Hi Manuel,
>   You worked on my problem!  Great.
>   So today what we have been doing to deal with the pre-release and
> lexical ordering problem involving pre-releases is this:
>     We impose a restriction on how the pre-release is identified.  So
> for example if you intend to end up with a final version-release of
> 5.0.0-1 and you want to first put out some betas or release candidates
> then we have to name them as, 5.0.0-0_beta1, or 5.0.0-0_rc1 and this is
> so that the lexical ordering for RPM will be correct.  In other words
> you must put the pre-release designation into the 'release' part of
> VERSION-RELEASE.  What we had seen developers doing previously was to
> name these as 5.0.0_beta1 or 5.0.0_rc1 (making the pre-release
> designation part of the 'version' string)  which then did not work for
> the lexical ordering of the final release of 5.0.0-1 because 5.0.0
> (version) was not lexically superior to 5.0.0_rc1.  So we were able to
> solve this problem without any code changes to distutils.  But this also
> presented a challenge for the other distribution targets such as 'sdist'
> because they were totally unaware of this 'version-release' combination
> and only knew about 'version'.  So as a workaround we were doing this:
> # WORKAROUND
> # define both version AND release
> version='5.0.0'
> release='1'
> # combine them for all targets except 'bdist_rpm'
> if sys.argv[1] != 'bdist_rpm':
>     version = version+'-'+release
> So this wasn't perfect but it actually worked quite well and we could
> get 'sdist' to work properly in conjunction with 'bdist_rpm'.
> So now with your patch all the targets should be able to set and use
> both 'version' and 'release' and we don't need our workaround and that
> will be great.
>
> 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/

Example is not the main thing in influencing others.  It is the only thing.
		-- Albert Schweitzer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090311/bab54385/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090311/bab54385/attachment.pgp>