[Distutils] SOLVED: bdist_rpm and pre-release python packages / eggs (was: pre-release versioning problems with sdist, bdist_rpm, bdist_debian)

[Gerry Reno]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20090312/27459176/attachment.htm>