Joe Morris wrote:
On 05/06/2008 05:39 AM, Linda Walsh wrote:
This topic is not intended at those who only upgrade a system by running the "official" upgrade procedure ... "offline" (not usable for other tasks). <snip> Anyone else interested in this subject? Is there a better place to find people who might be interested or know about such tools?
I don't think this would be possible (or so far from ideal as to not be too useful). Several limitations come to mind, i.e. newer versions of rpm needed, or glibc, which affect every rpm package in a new distribution. From what I have learned over the years is replacing glibc on a live system is not a good idea. That is why the offline upgrade is best. Upgrading a live system has a lot of pitfalls that would probably make it a nightmare in practice.
And when offline upgrading is not an option or when it is too costly? You just tell people "too bad?" What about people who don't want to do it the Windows way? Some things require restarting the machine -- currently, on linux, kernel upgrades still usually require a reboot -- but features are being worked on in linux to eliminate that requirement as well. If the *kernel* can do it, tell me one problem that an application has that can't also be overcome? It's also, IMO, poor engineering practice to change everything at once. If you do, you can't tell what has broken where. You upgrade everything at once, and when things inevitably don't work the first time, or immediately, there are way too many possible causes to even begin giving you a hint. But -- like in upgrading incrementally - - from 10.2 -> 10.3, I found the NFS server in 10.3 to be broken/non functional, but reinstalling 10.2 still worked. But with a whole-product upgrade I did on another machine -- I had no clue why NFS wouldn't serve. I gave up trying to track it down -- I had "scheduled" a few hours for what was to be an "easy" auto upgrade -- and it broke things (its a rare upgrade where nothing breaks). It wasn't until I did an incremental update on a more *key* system that I found the problem was specific to the 10.3 NFS server package, and that if I "backgraded" my 10.3's NFS-server package to 10.2, it started working. So in *STRONG COUNTER* to your statement about possibilities -- I find it is nearly impossible for me to upgrade one of my systems automatically and *NOT* have something break. (I'm not using caps for "yelling", just contrasting emphasis to make the point that one (or me, in particular :-)) can be 'screwed' either way. :-) *sigh*. Oh how I wish for SGI's IRIX's "inst" updating package -- was *SO* advanced compared to what's available these days. It could tell you how much space was taken up on *each* partition/volume by installed packages (or what the space Delta would be for adding/removing). And the only time you needed to take the system "offline" (officially) was to replace the 'base' system containing the kernel, drivers and immediate utils to boot the system. Even that was able to be "worked around" for interested parties. The only time I had to install from "offline" (booting from mini-root), was to "*CROSS*-grade" to a different product variation (Trusted IRIX), which had to go through and set the default security permission fields on all of the files and boot from a security-enabled kernel that could interpret and set such flags (and wouldn't work on a normal FS). Sadly -- it is amazing how many computer science advances and features are developed, and *LOST*, as new OS's and new programmers take the place of the previous generation(s). Happened *before* me, and has happened while I've been in the field, and is actively happening again. And so many people, sadly, think that the "new features" are so "cool", and don't realize that computers already had these features 10-40 years ago and that due to industry practice of hiring young cheap programers and "axing" older, experienced workers, how much established knowledge and research is lost. So many advances in computers are *lost*. With complete new "myths" and practices replacing old practices and knowledge. How many people believe that programs released with bugs is "normal"? It didn't used to be. There was exhaustive testing and real alpha/ beta periods that looked at bug-found rates. Only when bug-find rates had dropped below certain levels would products be allowed out -- and in some cases (*important* programs used in hardware control, embedded systems, and secure systems, testing was exhaustive -- with required metrics on test suite coverage). How often is that done today? Isn't the normal practice today to release "Beta" quality products as shipping products and expect that in-field patching will be used to compensate for lack of in-house, pre-release testing? Sorry for long note and to anyone where I'm 'preaching to the choir'. FWIW, while those who do not know the past are doomed to reimplement and repeat it, that *DOESN'T* mean they are not intelligent. It's just that the needed "learned" knowledge base gets larger and isn't adequately sifted and summarized into industry standard (best) practices. Also, FWIW -- I've been working on a script to do/implement the incremental upgrade process (at least as a helper) to handle tasks that have traditionally had to do myself. I can feed the output of an RPM command and it's "errors" into my script, and it can tell me the next thing to try (not complete, but handles many common cases). Ex: I feed output from an error, a message in a log file (even has junk before and after the rpm command due to being from a test-install-script log file) the rpm command) like: EXEC(nobit): /bin/rpm -Uhv --test i586/wv-1.2.2-75.i586.rpm, stat=256, out=error: Failed dependencies: libgsf-1.so.114 is needed by wv-1.2.2-75.i586 my script outputs the "next" rpm command I should try: /bin/rpm -Uhv i586/wv-1.2.2-75.i586.rpm i586/libgsf-1.14.5-23.i586.rpm i586/librsvg-2.18.2-9.i586.rpm i586/gnome-vfs2-2.20.0-3.i586.rpm NOTICE: it doesn't just find the package containing missing dep, but also finds dependencies needed by libgsf (librsvg) and those needed by librsvg(gnome-vfs2). It isn't a finished script, and may not be 100% correct in every case (yet :-)...but there may be diminishing returns for arcane cases for a tool designed to be an "assistant" but it can find and deal with a few problems. Blessings -- and hey -- it's only a 'myth' that if you sail too far you will fall off the edge of the world or be eaten by sea monsters. Many people might die trying to disprove it...and there may be mutinous problems, but that doesn't mean the widely believed myth is true. :-) (Though I'm sure sailing "too far" wasn't officially supported in those days -- since no official wanted to encourage ventures that might cause lots of problems for people. *sigh*... Do we ever really _know_ what is really true? Linda -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org