On Sat, 2005-05-28 at 15:37, Lamar Owen wrote:
No, I am looking for a solution that provides what a typical user needs,
Who is the typical user? CIPE users aren't, for one. Neither are radio astronomers, for that matter. :-)
OK, I meant a 'normal' user, in the sense that the normal range extends well beyond the average and covers a lot of people. Obviously if you are looking for backwards compatibility and the ability to upgrade individal apps without breaking others, you are someone who has been using Linux a while. And if you are raising the issue on forum for an RPM-based distro, even if you are capable of compiling bits and pieces from source, you probably prefer to drop in rpms where possible.
could interoperate independently. A system as bundled by Red Hat is going back to the DLL-hell that windows users used to experience.
Not exactly. RPM dependency issues can be solved with intelligent library versioning; for the most part binaries that run under RHEL3 can run under RHEL4 using the compat-* packages built for that purpose.
So what was the problem with taking perl to 5.8.3 or later on RHEL3.x again? Or having multiple versions of the same app on the same machine so an usupported new release of something did force any conflicts with supported software?
For the most part, the same problem does not exist on Linux. Take, for instance, the way theKompany distributes RPMs. They have a single binary RPM for each package, with a 'thekompany-support' base RPM for the basic differences between systems. For the most part, this single binary will install on virtually all modern RPM-based Linux dists.
So why does anyone consider it a good idea to have a gazillion different copies of things like this in separate core and update repositories for RHELX/FCX/CentosX versions?
So the lib versioning problem can be addressed, but it has to be very carefully addressed. The most extreme example is Cinelerra, which, last I looked, was built fully statically linked and would basically run anywhere.
Static linking should be a last resort, when you think about what that does to disk space, memory usage, and startup time, not to mention the need to update every package that has it's own copy of a fixed bug.
Ah, but there is more than one 'it' in the LTSP case. The server doesn't necessary have to run on odd hardware;
Yes, they are schools, often running on donated equipment even on the server side and even if they had something from the supported list for the RH7.3/RH8/FC1 based versions they probably can't afford to replace it to match what the FC2/FC3 versions need.
it's the thin client that must run on oddball hardware (I know how it works; I'm beginning to deploy an LTSP setup at a private school on CentOS4 (with KDE-Redhat to get the modern desktop apps).
Those sound like good choices, assuming you don't already have backwards compatibility issues with hardware, filesystems, or applications that you want to keep. But note that what you are doing isn't at all unusual, yet you've already seen that it doesn't match what a mainstream distribution provides. And you'll probably still eventually want updated OOo, firefox, and evolution versions if they do version-level upgrades before RHEL/Centos - you are just coming into the cycle at a better point then you would have with Centos3.
What's missing is something that fills the gap between a user having to rebuild from source himself and subsequently support the updates the same way forever and the downrev repository versions.
It's called Gentoo, and while you need to rebuild from source once there is a binary distribution mechanism available. But even then, the way Gentoo is built you could end up with some really odd dependency issues.
I suppose I should try that. I've grown accustomed to the RedHat way of doing things, but maybe I can go the 'one app per box' route with Centos3 and 4 for some things and consolidate all the weird stuff on a few boxes with Gentoo's source rebuild capability. I just don't like the feeling of not having an easy upgrade option on separate items.