[SciPy-user] bdist_rpm build error in scipy_core from CVS

[Fernando Perez]

Stephen Walton wrote:
> Hello, Fernando,
> 
> Fernando Perez wrote:
> 
> 
>>OK, many thanks for tracking this down.  I have a more generic 
>>question though, now that you're familiar with my approach: do you 
>>agree with it?  What I concluded was that the RPM 'arch' flags were 
>>not sufficient to address the needs of something like ATLAS,
> 
> 
> This approach works for me.  I was not aware of the $YUM<N> flags, and 
> agree that it does neatly solve the whole problem.  I take it, by the 
> way, that you use a kickstart file to get the whole process rolling when 
> you build a new system?  I'd like to see that, probably off list.

Yup, I have a setup for this.  Please pester me directly if I haven't sent it 
in a day or two, I have to organize a few files before passing it to you, so 
just drop me a line if I let it slip.

> I would only add a couple of minor suggestions about your pybrpminst 
> script, realizing this is something like a personal taste.  My overall 
> goal is to only do those things as root which must be done as root;  in 
> particular "setup.py bdist_rpm" should be done as an ordinary user.  See 
> footnote below.  Thus, I'm changing my local copy of pybrpmdist to have 
> an 'sudo' in front of the lines which touch the depot.  I'm also 
> deleting the 'yum install' from my copy, preferring to rely on my 
> automatic nightly yum updates to do this for me.

Valid changes indeed.  I'll probably do the same.

> One comment/caveat:  even ATLAS's naming convention may be a bit coarse 
> grained.  I've built ATLAS on my laptop (Athlon M CPU) and an Athlon 
> desktop.  ATLAS correctly sees that the cache sizes are different and 
> builds accordingly, even though both architectures end up called 
> ATHLONSSE1.  Clint Whaley (ATLAS author) designed ATLAS for maximum 
> performance, and wrote it on the assumption you would always tune it for 
> each machine you're on.

I guess one could always extend this to renaming the ATLAS tarballs with extra 
tags for cache size and the like, even if the default ATLAS makefile doesn't. 
  After all, it's just a string which defines what ATLAS thinks of as a 
'unique architecture', which can be made still somewhat generic (it doesn't 
have to be unique to a given individual machine).

> P.S.  A true story showing why it is important not to build as root.  
> The first version of the C compiler which HP shipped with HP-UX 10.20 
> had an interesting bug:  it attempted an unlink of /dev/null.  Of 
> course, this succeeded if you ran cc as root and then your system 
> mysteriously locked up.

A version of LyX a while back had the exact same bug, though I don't remember 
if it was at ./configure or at install time.  Lots of people ended up all of a 
sudden with unbootable systems :)

Cheers,

f