Manuel Amador (Rudd-O) wrote:
> 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.
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.
Regards,
Gerry