OK, I am at the limit of my patience, so this will be the last mail I will write about this to you, ever.
First of all, my work has already been given good reviews by people involved with distutils.
Second, I will absolutely not build an extension that must be enabled explicitly by the packager. This is intended to be default behavior.
There is good reason for that decision.
The current default behavior *breaks RPM package managers like RPM, Yum and Smart*. Let me reiterate that: the current distutils is BRO-KEN. My patches merely fixing this breakage, which is common to ALL distributions.
When this gets into distutils, casual packagers won't have to troll the documentation to figure this out, or be baffled when their "beta" RPMs upgrade their stable releases because "Oh, I didn't know I had to pass this --unbreak- me option to bdist_rpm!"
There is no engineering reason to make a bug fix optional. This is a bug fix. It must replace the broken behavior. Heeding your baseless advice would defeat the purpose of my work.
Third: Any future people looking into distutils have *nothing* to decipher -- the code is documented and the rationale is explained a bit in the code and well in the bug reports and across the Internet in terms of the RPM versioning algorithm.
Fourth: The modifications aren't Fedora-specific. They work correctly across all RPM distributions, whether you want to admit it or not. I am not barging in and taking over distutils for Fedora, and for you to frame the discussion in terms of "Fedora vs. The Others" is just corrupt and dishonest.
IOW: I REALLY REALLY do not want to hear you lie "But this is Fedoraism" again.
And finally, even if some wacko distributor wants to put a BIG ASCII PENIS on the release tag (which, by the way, is a valid string), they can always patch my work out of distutils just as all distributions have been doing all along. Enjoy your broken behavior -- the rest of us actually want good RPM packages.
Fifth: you have been given a mechanism to disable the rewriting which you so loathe. No rewriting (thus reverting to the old, BROKEN bdist_rpm behavior) happens if:
1) your package is a final stable release 2) you put a non-numeric character in your setup.cfg's release= config item, such as 2mdk or something like that.
This ought to cover any hypothetical policy that is ass-backwards and likes to generate broken prerelease packages that upgrade stable ones. See big ASCII penis comment above, it fits perfectly here.
Sixth: you complain about the rewriting:
$ python test2.py rewrite 3.3beta1 4333 3.3beta1-4333 3.3-0.4333.beta1
How deficient are you that you can't understand how without the rewriting, 3.3beta1 RPM would upgrade 3.3-1 first final release?
TRY IT. DO THE LEGWORK. Do what I did, build two packages of the same code, one with beta in the version name, another without it, and see which one upgrades which other.
* bdist_rpm generates broken RPM packages if supplied with pre-release modules. It has always been broken. * My patches FIX this breakage in a manner that is compatible with all RPM distributions out there. This is not a new feature but a BUG FIX. * They do not require extra action by the packager because making a bug fix require manual intervention from the operator would be the epitome of imbecility. * They have been reviewed positively and I have been thanked personally for making them. The prognosis for their inclusion looks rather positive. * I have addressed every single of your complaints to the limit of my abilities, both with code and with detailed, reasoned justifications for the code. * Yet you object to them fiercely, with absolutely NO BASIS in engineering, and only a made-up distro rivalry that is simply false.
In addition, on the basis of this patch, I have created new distutils code that auto-detects dependencies based on egg metadata and adds them to the RPM. These patches have already been submitted to the various bug trackers, and without this patch you so much object to, it would have been technically impossible to deliver on that. Before this patch, people had to specify their dependencies twice, once in the requires.txt and another in the setup.cfg file -- a monumental, error-prone task to be done for tens of thousands of eggs -- and now, we have this. If you had your way, we'd be back in the stone age of manually preparing spec files for each and every Python module.
You have had repeated chances to make your case, and all you have come up with is this complaint that stinks of crab mentality, evidences a severe lack of technical ability to understand the underlying problem and its importance, and a false allegation that the patch engages in distribution favoritism just because it uses a fucking dot (which is now configurable, but doesn't really impact any distros negatively) for a separator.
I have had enough of this. From now on, you will be redacted from the recipient list in future conversations about this topic. I think it's time for you to visit http://www.sadtrombone.com/ . Now have some respect for my time and stop barging in on my inbox.
El Viernes 13 Marzo 2009, Gerry Reno escribió:
Manuel, Here's what I get with this patch: $ python test2.py rewrite 3.3beta1 4333 3.3beta1-4333 3.3-0.4333.beta1 $ python test2.py rewrite 3.3rc1 4333 3.3rc1-4333 3.3-0.4333.rc1
It is REWRITING the strings when we don't want them rewritten. And that was the point about putting this in an extension called by a commandline arg. Instead of going through all these callesthenics writing obscure code in bdist_rpm.py just write your simpler code into an override module and call it via a commandline option. That way people who work on bdist_rpm in the future don't have to decipher all this Fedora-specific code. Why do you resist doing it this way? Why do you feel you have the right to come in and take over bdist_rpm with Fedora-specific modifications?