Crispin Cowan wrote
Naturally using SLES/SLED for your important boxes, and openSUSE for your other machines, is the intended design. We put a lot of work into the common code base, so that packages for SLES work on openSUSE and vice versa.
And we often used that in the past! Like running the SLES kernel on a host that would for unknown reasons crash with every SuSE kernel. Last use that really really saved us: The linuxrc of SuSE 10.1 can't load modules specified on the pxe command line before starting the hardware probe. Therefore we couldn't fix the detection of SCSI controllers in an autoyast process. The solution was to used the linuxrc from SLES 10 (that had the bug fixed already) for installing the SuSE 10.1 hosts with autoyast. That *really* rocks :-))
You could solve this problem by deploying more SLES instead of openSUSE. But that costs money.
And not all our hosts can run SLES or SLED, for technical reasons.
So instead, you could solve this problem by upgrading the .1 machines to 2 or .3, which certainly have not expired before the next SLES comes out. But that costs effort.
And it gives more problems: binaries compiled on the SLES hosts won't run on the SuSE clients in many cases. If a glibc upgrade happens, the systems are more or less incompatible. That's a real problems in our environment, although I guess that the problem is not so big outside universities/scientific environments...
Saving you from forced upgrade effort is the value proposition that makes SLES cost money, so generically if upgrading too often is the problem, then buying SLES subscriptions is our proposed solution.
We have three-year subscriptions at the moment, but all the desktop clients at the users desks have to run SuSE due to a specially designed diskless system. Well, maybe that problem would be gone if there was a SLESD = SLES+SLED+SDK release and if packman released for SLED (although, due to the common code base, it should work...).
Your schedule of using only .1 releases and rolling them just as the new SLES release comes out is elegant. I don't think that the company *deliberately* scheduled the expiring of .1 support and release of new SLES editions just to prevent your schedule from working; I don't think
I guess this time the problem was also caused by the delayed release of 10.1.
we're that clever :) But now that you've pointed it out, I will ensure that it is at least a conscious decision.
Well, releasing the SuSE version that is the code base for the next SLES about 3-4 months before the former code-base SuSE is dropped would be enough. When I've extensively tested and configured the new SuSE, I'm almos done because the SLES configuration doesn't need much more work for a common code base. But switching from SusE 9.1 to 10.1 takes more than a few weeks to detect and solve all problems the users could step on in advance... So, if the lifetime of two suceeding SLES-code-base SuSE releases could overlap for three months (and if the next SLES is release within that three months), that would really help :-)) BTW: have you given up the "major release is birthday of SuSE"? If 10.1 was released two years after 9.1, you have, I guess... cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *