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

> Mandriva link:  http://wiki.mandriva.com/en/Policies/RpmSpecProposal

Thanks for providing the link.  Which is a PROPOSAL, not a polcy.  On a user-
editable WIKI.  And on top of that, what you say about versioning style is in 
NO WAY backed by that document.

Now we know for a fact that my patch is neither in conflict with Mandriva 
policy, nor will fail to work there.  This is the kind of fact-based exchange 
I enjoy.

> Again, the core software should not enforce one distros packaging
> policies.

We already established that the Mandriva policy is not in conflict with 
Mandriva policy or any other policy that you have quoted so far (none, 
really), so the prescriptive argument you are making has no basis in fact -- 
It's just dogma.

> Why do you keep saying this?    What is preventing you (the human) from
> filling in the version and release fields with "fedora-compliant
> strings"?   The core software does not have to know anything about
> fedora.  But you do.

If you need to know: cheese shop eggs come using a particular python policy 
for naming them, a policy that was defined by setuptools' dependency handling.  
This python policy is incompatible with RPM lexicographical order.  This is, 
in a nutshell, the source of the problem.

Therefore, the bdist_rpm patch needs to adapt the version to an RPM 
lexicographically valid form.  My patches do exactly this -- they merely adapt 
the bdist_rpm version and release in very specific cases (pre-release 
packages) which ought not to matter for a distributor making a stable release.  
In addition to that, my code works across distributions and is not in 
contradiction to any policy.

Without my patches, there needs to be a way to override the version of the 
package in setup.cfg, and in addition to that, each package in the cheese shop 
would need to be modified in order to be buildable.  That's thousands of eggs.

You're invited to talk to all the python egg developers yourself if you 
disagree with me.  Me?  I prefer practical solutions, thus the patch.

> That's a lexical ordering problem.  That should be fixed by the human
> making sure that he declares the version and release with proper strings.

Well, I'm sorry but the version is not overridable in setup.cfg.  So you 
either use my patch, or chao eggs.

> > I have a solution that works in fedora, rhel and centos, and likely
> > works just as well on other RPM distros including Mandriva and SUSE.

> Your solution LIMITS the version and release strings to ONLY fedora
> packaging style.    Mandriva users don't want that.

FYI: There is nothing in the Mandriva policy supporting this statement.

> They want to build RPM according to their own packaging policy for Mandriva 
but your patch will not let them because it enforces fedora policy.    THAT'S 
WRONG.

Again, the policy link you gave provides no basis for your argument.

>
> > Do you have an alternative solution?
>
> Yes, I do.   Remove all artificial restriction on formatting on the
> 'version' and 'release' strings. 

I have not introduced any artificial restrictions at all.  This is just a lie.  
I'd appreciate it very much if, in the future, you refrain from telling lies 
about my work.

> All that's necessary is for both the
> 'version' and 'release' strings to be available to all the distribution
> command which it is not at the moment.  That's it.   Nothing else is
> necessary.

You are encouraged to write that patch, then make every single egg developer 
put stuff in their eggs' setup.cfg files.  Have fun draining the ocean.

> If you want to do some policy enforcing thing, then put
> it in some type of optional extension called from a special command line
> option.

Look, this back-and-forth is pointless.

* If you in some capacity have some control on what goes into the distutils 
repo, then reject the patches.  The Fedora/RH people will probably pick them 
up anyway, because it has value for tens of millions of users out there.

* If you are a Mandriva developer, and there is real basis for your argument 
(despite the policy document you quoted which does not support it), then you 
are welcome to include a patch to the patch in your Python sources (you 
already include several patches, so it should not be a problem) which should 
be a change of a few characters in my patch to confirm to Mandriva policy.

* If not, then either produce code that has the same net results as mine, or 
let's stop this argument.

This bickering can be reduced to the following: I have working code that will 
work on Mandriva too.  You have a baseless complaint with a proposal that 
would require thousands of people to do extra work, and no code to boot.

luck,


-- 

	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: Eiffel 65 - Sopra un palco per tutto il mondo
Blessed is the man who, having nothing to say, abstains from giving
wordy evidence of the fact.
		-- George Eliot

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