Rick Troth wrote:
In the z/VM world, the customers fought really hard (some might say they complained really loudly) so that CP and CMS could be serviced separately. The vendor complied. But in Linux land, the separation between the various RPM-based packages is much less clear than the clean barrier between CP and CMS. So even a willing and listening Linux distributor may have a real challenge meeting our demands.
VM isn't my strong suit, but as I understand it CP is the hypervisor, and CMS a guest operating system. In a Linux world, the kernel most corresponds with CP. Compared with VM, Linux is much complicated because because the bits that run under its direction like to play with each other. For installation and maintenance purposes, the "things" that run under the control of the kernel _are_ well separated. It's perfectly possible to replace apache and php separately from each other. The special requirement is that each has been customised to whatever extent is necessary to play with the versions of its friends it's likely to find. Building from source, using the configure script is doing this necessary customisation. It's not a difficult thing for an administrator to do, but close attention to the suppliers documentation is required. A configure script finding some library missing might do one of two things: 1. Complain loudly and quit. 2. Turn off the corresponding feature. It might not even tell you, and if it does and there are thousands of other messages (quite possible), you might not notice. Happily, Red Hat, SUSE and Debian sort this all out for you for stuff they include in their standard, supported set of software. Not only that, but the spec file enumerates all the packages required in order to build it again. (Mostly). If you get a source rpm, or a tarball with an imbedded spec file from php.net (for example, I don't know the actual situation here), then it's possible that those build dependencies are not fully specified, maybe because required packages on (say) RHEL might have different names on (say) SLES or Mandrake or Turbo Linux. Upstream suppliers tend to way the package to "just build." This is why I suggest that, of your EL doesn't have the package you want, you should look first at the development version. It does not guarantee easy success, or even success at all, but if it works it's more likely to work well because the packages are engineered (more or less) by the same people. -- Cheers John -- spambait [email protected] [email protected] -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
