Ken Hall said: >The downside (I've found) of the SuSE philosophy on maintenance of the SLES >series is that they never (normally) release a new VERSION of a product to >fix a problem. They just retrofit patches to the version supplied with the >distro. Hmm. Sounds almost like IBM's philosophy of shipping PTFs and APARS for the current release. Which would you say has more risk associated with it? Installing a patched version of the current release, or installing a brand new release? I would (usually) prefer to install the patched version, myself. A lot of things can change between releases of a package, including inter-product dependencies, configuration file changes, startup script requirements, and on, and on. I would rather be relatively sure that the only thing different between what I'm running now and what I'm going to be installing is that a bug was squashed.
>This has been a major headache for products like Samba, where the many bug >fixes come fairly frequently in version/release upgrades. The version of >Samba that came with SLES7 was 2.2.0a, which turned out to be just about >unusable, so we had to "roll our own" versions of 2.2.5 and up. I would be curious as to what you found unusable about Samba 2.2.0a. I'm still running that in production on some of my systems. From my perspective, unless there are features in the newer versions of a product that you just cannot live without, you're better off installing patched versions of the current release. You can just about kill yourself trying to stay current with all the Open Source packages out there. The "release early and release often" development philosophy is good for the community in general. "Install early and install often" is probably not a good idea for a particular organization. >Same thing with Openldap, and the latest version won't even build properly >on SLES7 because SuSE had to add patches to it that aren't in the base >versions yet. This is one of the hazards you run into when you decide to get away from being a consumer of a package, and into the role of developer. It's happened to me any number of times, and it's rarely been an easy problem to surmount. If it's important enough to me, I follow through. If not, I decide to try to wait for the next update from my distributor. >There also seem to be product features disabled or "missing", such as >Winbind in Samba, and quota support, sometimes because the various required >components aren't at the right level, or often for no apparent reason at >all. When this happens, there's almost no way to fix it and stay within >the "official" support scheme. Things like this are usually options that can be selected at compile-time. You should have the source RPM for the package, so you should be able to tweak the spec file for it to turn those on, if you really want them. You may find out the hard way, though, that they were left turned off for good reasons. (Similar to the reasons that Red Hat didn't turn on LVM in their 7.2 platform.) Linux distributors are not interested in gratuitously turning of functionality, since they'll usually get asked why something isn't available, when distribution xyz has it. (Again, take Red Hat 7.2 and LVM for example.) Mark Post
