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