(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