(Sorry to be a little talkative today, but I will easily refute everything.)
Les Mikesell wrote:
If you are moving binaries to any other machine, you are likely to have odd failures if you don't carefully control the libraries in the build environment.
The linker doesn't and cannot link 64-bit objects to 32-bit libs.
There's nothing else. Include files/etc. that are duplicated in 32-bit RPMs must be identical otherwise rpm doesn't install them together.
If you aren't moving them to some other machine, then you rarely if ever need anything but the native libraries and development header set.
That's the basic use case anyway: A user compiles his stuff on the frontend of the cluster and then submits his job.
The libraries are useful for 3rd party binary apps, but why build a 32bit app yourself if you are going to run it in a 64bit environment?
Three examples I have already given. To repeat one: a user has a code base that is not 64-bit clean? What am I to do? Tell him to f*******, fix it myself for him, or what?
I recall at least a couple of update conflicts/failure in the 5.x line caused by having 32bit versions of things installed on a 64bit host. Didn't those affect you?
Also already answerded: They forgot to copy the 32-bit updates to the 64-bit updates repo. In one case there was a real bug. This happend only a couple of times so far in the 5.x time frame. So what? There where other bugs as well.
And there is always the extra time wasted doing updates to libraries and programs you don't ever use.
They update with everything else, there's no bandwidth limitation for these machines and the discs are big enough. (The 'everything' I described shortly elsewhere + a lot of extras totals to ~16 GB of disc space. That's nothing.)
-Michael