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

[Gerry Reno]

Manuel Amador (Rudd-O) wrote:
> El Miércoles 11 Marzo 2009, Gerry Reno escribió:
> > Manuel,
> > Additionally, from a Python Distutils perspective, Distutils should
> > not be enforcing one distro's policy. There are RPM-based distro's that
> > DO NOT follow fedora's packaging policy.
>
>
> Well then, give me one packaging policy that is discordant or 
> incompatible with Fedora's packaging policy. I'm sure you can show us 
> that.
Ok, Mandriva comes to mind.  It's policy is different and allows more 
flexibility than Fedora's.

Besides, policies are meant for humans.  And policies change.  We don't 
need distro policies hard-coded into Distutils.  That makes for brittle 
code.


>
> Besides, we're not enforcing a distro policy here over all platforms. 
> My patches merely reformat the existing information to make it 
> lexicographically compatible with RPM package managers (which are the 
> SAME across all bdist_rpm distro targets), and that's it. You still 
> get to specify your release numbers if you want to, and the version 
> numbers are intelligently determined based on heuristics but in the 
> case of stable releases, they are just as they used to be before.
>
>
> > The software should only be
> > concerned with providing for the use of both the 'version' and 'release'
> > strings in all distribution targets. It should not concern itself with
> > HOW those fields are formatted.
>
>
> If distutils did only that and we were to reject the distutils patches 
> I wrote, then I would simply be technically unable to build Plone for 
> Fedora or RHEL. 
Why?  A distro's policy is defined for 'human' behavior for users of 
that distro.  Users of distro X should not be hostage to policies of 
distro Y.   'version' and 'release' should be formatted by humans for 
whatever distro is the target.  There should be no enforcement of any 
distro's  'packaging policy' over the fields.


Regards,
Gerry


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090311/66f571e0/attachment-0001.htm>