[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) rudd-o at rudd-o.com
Thu Mar 12 02:19:17 CET 2009

1) No, I'm not on the committee.
2) The policy is similar.
3) Both approaches cannot work in parallel because the period is 
lexicographically distinct to the underscore
5) The policy has been tested and takes advantage of the already-deployed RPM 
code in tens of millions of machines out there.  We do not know what sorts of 
malfunctions using underscores might cause.
4) The policy *does* make sense especially in the place you quoted it.  The 
release begins with 0.1 and increments to 0.2 0.3 0.4 whenever you change the 
package (add patches, modify specfile) but continue to use the same source 
package, which is the purpose of the release tag in the first place -- to mark 
a new release of the SAME source package.  Unfortunately, it requires that 
when a new beta source package (even one that is lexicographically later than 
the existing package) is compiled, the release must be bumped to upgrade it.  
My distutils packages explicitly punt this release bump to the packager so 
that he has control over which beta packages to push out.  And the reason that 
the release tag always begins with 0. in nonstable releases is pretty dead 
simple: so that the release package with version 0.9.8-1 (the first official 
stable release) can be lexicographically higher and is automatically updated 
with package managers like yum.

Guys, amirite?

> > 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


	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/

If you are what you eat, does that mean Euell Gibbons really was a nut?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090311/e94da45e/attachment-0001.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/e94da45e/attachment-0001.pgp>

More information about the Distutils-SIG mailing list