> Mandriva link: http://wiki.mandriva.com/en/Policies/RpmSpecProposalThat 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.
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.
It does conflict. See above.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, your patch makes changes to 'version' and 'release' based on Fedora naming policy. Not every distro follows Fedora package naming policy.> 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.
If that's the problem then fix it where the problem lies. In the egg naming policy in setuptools.> 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.
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.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.
Again, put this logic in an extension so it doesn't affect the core and call it from a commandline option.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 the patch logic in an extension called from a commandline option and leave the core alone.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.
Yes, there is. Mandriva naming is whatever will work in a spec file. Much less restrictive than Fedora.> > 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.
See above.> 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.
Manuel, here is part of your patch:>
> > 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.
+ 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.That patch needs written and if necessary I will write it.> 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.