[Python-Dev] peps: Update with bugfix releases.

[Ned Deily]

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