[Python-Dev] peps: Update with bugfix releases. (original) (raw)

Ned Deily nad at acm.org
Wed Feb 8 22:13:29 CET 2012

In article <4F32DF1E.40205 at v.loewis.de>, "Martin v. Lowis" <martin at v.loewis.de> wrote:

Am 05.02.2012 21:34, schrieb Ned Deily: > In article > <20120205204551.Horde.NCdeYVNNcXdPLtxvnkzi1lA at webmail.df.eu>, > martin at v.loewis.de wrote: > >>> I understand that but, to me, it makes no sense to send out truly >>> broken releases. Besides, the hash collision attack is not exactly >>> new either. Another few weeks can't make that much of a difference. >> >> Why would the release be truly broken? It surely can't be worse than >> the current releases (which apparently aren't truly broken, else >> there would have been no point in releasing them back then). > > They were broken by the release of OS X 10.7 and Xcode 4.2 which were > subsequent to the previous releases. None of the currently available > python.org installers provide a fully working system on OS X 10.7, or on > OS X 10.6 if the user has installed Xcode 4.2 for 10.6.

In what way are the current releases not fully working? Are you referring to issues with building extension modules?

Yes

If it's that, I wouldn't call that "truly broken". Plus, the releases continue to work fine on older OS X releases.

If not "truly", then how about "seriously broken"? And it's not quite the case that the releases work fine on older OS X releases. The installers in question, the 64-/32-bit installer variants, work only on OS X 10.6 and above. If the user installed the optional Xcode 4.2 for 10.6, then they have the same problem with building extension modules as 10.7 users do.

So when you build a bug fix release, just build it with the same tool chain as the previous bug fix release, and all is fine.

I am not proposing changing the build tool chain for 3.2.x and 2.7.x bug fix releases. But, users not being able to build extension modules out of the box with the default vendor-supplied build tools as they have in the past is not a case of of all is fine, IMO.

However, this may all be a moot point now as I've subsequently proposed a patch to Distutils to smooth over the problem by checking for the case of gcc-4.2 being required but not available and, if so, automatically substituting clang instead. (http://bugs.python.org/issue13590) This trades off a certain risk of using clang for extension modules against the 100% certainty of users being unable to build extension modules.

-- Ned Deily, nad at acm.org

More information about the Python-Dev mailing list