<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Manuel Amador (Rudd-O) wrote:
<blockquote cite="mid200903110921.48576.rudd-o@rudd-o.com" type="cite">
  <meta name="qrichtext" content="1">
  <style type="text/css">p, li { white-space: pre-wrap; }</style>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:<br>
  <p style="margin: 0px; text-indent: 0px;"><br>
  </p>
1.2dev: refers to unspecified not-even-alpha quality checkout or source
drop<br>
1.2dev-r5667: refers to the checkout of revision 5667, not-even-alpha<br>
1.2a1: refers to Alpha 1 of intended version 1.2<br>
1.2a2: refers to Alpha 2 of intended version 1.2<br>
1.2b1: refers to Beta 1 of intended version 1.2<br>
1.2: refers to official 1.2 release<br>
  <p style="margin: 0px; text-indent: 0px;"><br>
  </p>
Note NO UNDERSCORES. In order to satisfy the fedora package naming
guidelines and RPM's lexicographical sort, this is what happens within
my patches:<br>
  <p style="margin: 0px; text-indent: 0px;"><br>
  </p>
1.2dev: version 1.2 release 0.0.0dev REGARDLESS of user-specified
release <br>
1.2dev-r56: version 1.2 release 0.0.56devr REGARDLESS of user-specified
rel<br>
1.2a1: version 1.2 release 0.&lt;user-specified release&gt;.a1<br>
1.2a2: version 1.2 release 0.&lt;user-specified release&gt;.a2<br>
1.2b1: version 1.2 release 0.&lt;user-specified release&gt;.b1<br>
(note in the last three it is the responsibility of the builder to bump
the &lt;release&gt; manually, there is really nothing we can do about
it)<br>
1.2: version 1.2 release &lt;user-specified release&gt;<br>
  <p style="margin: 0px; text-indent: 0px;"><br>
  </p>
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".<br>
  <p style="margin: 0px; text-indent: 0px;"><br>
  </p>
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.<br>
  <p style="margin: 0px; text-indent: 0px;"><br>
  </p>
I am exhausted.<br>
</blockquote>
Hi Manuel,<br>
&nbsp; Let me share with you what we had implemented and the POLICY that we
put in place with regards to VERSION-RELEASE strings.&nbsp; We did not look
at this from egg standpoint as we just distribute RPMS.<br>
<br>
I sent this to Tarek a while ago:<br>
What I had implemented seems to have the VERSION-RELEASE string issue
solved using a 'workaround' and a manual policy for the moment.&nbsp; It
would of course be
better if distutils just did this automatically but this is at least
working.&nbsp; 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.<br>
<br>
#WORKAROUND:<br>
What I did was in setup.py added:<br>
========================<br>
version = '5.0.0'<br>
release = '0_rc3_00001681'<br>
<br>
if sys.argv[1] != 'bdist_rpm':<br>
&nbsp;&nbsp;&nbsp; version = version + '-' + release<br>
========================<br>
<br>
In setup.cfg added:<br>
========================<br>
[bdist_rpm]<br>
# release must exactly match 'release' as set in setup.py<br>
release=0_rc3_00001681<br>
==================<br>
# END WORKAROUND<br>
<br>
<br>
<br>
And then I setup the following policy regarding VERSION-RELEASE naming:<br>
(this example uses bzr as source code control system but you can
substitute
svn, rcs, or any other type of sccs)<br>
<br>
Development code:<br>
version="5.0.0" <br>
release="0_00012345"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (where 00012345 is the
revision number from bzr in ZERO-PADDED FIELD OF 8)<br>
tarball: foo-5.0.0-0_00012345.tar.gz <br>
rpm:
foo-5.0.0-0_00012345.noarch.rpm<br>
<br>
Alpha code:<br>
version="5.0.0" <br>
release="0_alpha1_00123456"<br>
tarball: foo-5.0.0-0_alpha1_00123456.tar.gz <br>
rpm:
foo-5.0.0-0_alpha1_00123456.noarch.rpm<br>
<br>
Beta code:<br>
version="5.0.0" <br>
release="0_beta1_00234567"<br>
tarball: foo-5.0.0-0_beta1_00234567.tar.gz <br>
rpm:
foo-5.0.0-0_beta1_00234567.noarch.rpm<br>
<br>
Release Candidate code:<br>
version="5.0.0" release="0_rc1"<br>
tarball: foo-5.0.0-0_rc1.tar.gz <br>
rpm: foo-5.0.0-0_rc1.noarch.rpm<br>
<br>
Release Candidate code fix:<br>
version="5.0.0" <br>
release="0_rc1_00345678"<br>
tarball: foo-5.0.0-0_rc1_00345678.tar.gz <br>
rpm:
foo-5.0.0-0_rc1_00345678.noarch.rpm<br>
<br>
Final Release code:<br>
version="5.0.0" <br>
release="1"<br>
tarball: foo-5.0.0-1.tar.gz <br>
rpm: foo-5.0.0-1.noarch.rpm<br>
<br>
Notice that lexical ordering is proper in all cases. Even where the
alpha, beta, rc releases may be followed by a bzr fix revision.<br>
The ensures that both tarballs and packages such as rpm will contain
the same VERSION-RELEASE designations.<br>
<br>
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.<br>
<br>
<br>
Regards,<br>
Gerry<br>
<br>
<br>
</body>
</html>