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.
--
Les Mikesell
lesmikesell at gmail.com