>>> On Thu, May 22, 2008 at 11:38 AM, in message <[EMAIL PROTECTED]>, Wayne Driscoll <[EMAIL PROTECTED]> wrote: > The requirement that a version upgrade requires a full re-install and then > copying of the data is one of the big issues I see with bringing Linux into > a System z shop and having experienced z folks work on it. For z/OS or > z/VM, you rarely (closer to never but...) have to move application data over > in order to build a new OS. There are systems that have been migrated from > MVS/SP on 24 bit hardware that are today running z/OS on 64 bit hardware, > and the data hasn't needed to be moved.
I know others have touched on this already, but I wanted to add to the conversation a little bit. With SLES, a full re-install and then copying of the data is most definitely not a "requirement" unless you try to skip too many levels of releases that came out in between where you're at and where you want to wind up. The reason why most people recommend doing this largely revolves around a couple of things: - Open source packages evolve fairly rapidly. Names can change, or be replaced by a more "worthy" (make up your own definition) one. Or, they may simply go away, and need to be replaced. (FreeS/WAN, zebra, and so on.) This can result in less than perfect upgrades in terms of new packages being selected, and old ones being removed. It's not impossible, or even particularly difficult, just tedious to clean that up. Multiply that by 10, 50, or 400 systems, and the job gets ugly very quickly. - Configuration files evolve along with the packages that own them. This can be for a number of reasons, such as improved defaults for better security, updated capabilities with new parameters, entirely new packages, etc. This is, conceptually, no different than trying to migrate SYS1.PARMLIB from one release of MVS to another (or JES2 parms). Having gone through that exercise enough times I can state that it's not much harder for Linux than MVS. It largely boils down to familiarity, or lack thereof. In some cases, new configuration files are put into place and the old ones saved. In others, the new configuration file is put on the system, but with ".rpmnew" on the end. The distribution providers try to automatically generate a list of all the .conf files you need to examine, but I don't know how good a job is done, since I haven't really looked closely. Mark Post ---------------------------------------------------------------------- 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
