Thomas Vander Stichele added the comment:
Well, I just checked, and from 2.3 to 2.6 opcodes were only added, existing
ones were never renumbered.
2.7 however reshuffled a bunch of them, for no apparent reason at all:
$ diff -au opcodes-2.6 opcodes-2.7
--- opcodes-2.6 2010-12-04 20:47
Thomas Vander Stichele added the comment:
Really ? Is this documented somewhere ? Do you know of any other case where a
number for an existing opcode was changed ? I can't find any so far.
--
___
Python tracker
<http://bugs.python.org/i
Thomas Vander Stichele added the comment:
Maybe I am missing something, but why was it ok for this patch to move
EXTENDED_ARGS from 143 to 145 ? I thought the numbers for opcodes were part of
the ABI ?
--
nosy: +thomasvs
___
Python tracker
<h
Thomas Vander Stichele added the comment:
It's too bad this is closed out of date because
a) the macro is still there being distributed
b) it simply hangs!
c) there's no easy way to figure out that you should be using something else
instead.
I spent a few hours of my life figuri
Thomas Vander Stichele added the comment:
What do you mean, it's frozen ? Without the patch you're already breaking a
third party tool, namely rpm. What other tool worth caring about that uses
bdist_rpm could possibly get broken by fixing an obvious bug ? Why is it so
impossible
Thomas Vander Stichele added the comment:
Ok, so this patch can go in as is except for changing .gz to * ?
--
___
Python tracker
<http://bugs.python.org/issue644
Thomas Vander Stichele added the comment:
Hi Toshio,
I'd probably also go for the wildcarding, but you'd still need to
'change' the INSTALLED_FILES file to do so, so you'd still use the same
mechanism.
--
___
Python tracker
Thomas Vander Stichele added the comment:
Attaching a reworked patch of the patch attached in
http://bugs.python.org/issue1169193
This worked for me on f-11, with python 2.6
--
keywords: +patch
nosy: +thomasvs
Added file: http://bugs.python.org/file15383/distutils.bdist_rpm.patch
