Manuel Amador (Rudd-O) wrote:
> Mandriva link:

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.
That is the ONLY policy there is for Mandriva.  So, if you like, then you can say the policy is whatever 'version' and 'release' naming that will work in an RPM spec file.  And that's way more flexible than Fedora's policy.
And Mandriva is just one example.  You have other distros that do not use Fedora naming policy and you have all sorts of derivatives of these distros, none of which are using Fedora packaging policy.

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.
It does conflict.  See above.

> 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.
Again, your patch makes changes to 'version' and 'release' based on Fedora naming policy.  Not every distro follows Fedora package naming policy.

> 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.
If that's the problem then fix it where the problem lies.  In the egg naming policy in setuptools.

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.
Manuel, please put this policy stuff in an extension that will override the core.  Not everybody uses eggs or cares about eggs.  Or what problems egg people have with RPM. 

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.
Again, put this logic in an extension so it doesn't affect the core and call it from a commandline option.

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.
Again, put the patch logic in an extension called from a commandline option and leave the core alone.

> > 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.
Yes, there is.  Mandriva naming is whatever will work in a spec file.  Much less restrictive than Fedora.

> 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.
See above.

> > 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.
Manuel, here is part of your patch:
+        version = self.distribution.get_version()
+        release = self.release.replace('-','_')
+        import re ; regex = '[^0-9\.]'
+        splits = re.split(regex,version,maxsplit=1)
+        firstnonalnumchar = re.findall(regex,version)
+        if len(splits) == 1:
+               pass
+        else:
+               version = splits[0]
+               release = "0." + release + "." + firstnonalnumchar[0] + splits[1]
         spec_file = [
             '%define name ' + self.distribution.get_name(),
             '%define version ' + self.distribution.get_version().replace('-','_'),
-            '%define release ' + self.release.replace('-','_'),
+            '%define version ' + version,
+            '%define release ' + release,
Your patch is enforcing restrictions on 'version' and 'release' that are directly from Fedora.   If some other distro user creates 'version' string that happens to match your pattern, his strings will be changed.  That's why I said that the better way to do what you want is to leave the core code alone and put your policy logic in an extension that overrides the core and call it from a commandline option.   This would be more community friendly and that way you have what you want and you don't impact other distro users.

> 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.
That patch needs written and if necessary I will write it.

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