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) <rud...@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) <rud...@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
