Carlos E. R. wrote:
Because you can not do it one package at a time.
First, let me be clear -- I said package or package group. If you install an rpm and *satisfy* its dependencies, it *should* run if it's dependencies are properly specified.
Don't you understand? The moment you replace glibc - and you need to do it - - all the old programs will not run. System down.
Negatory.... Any programs already running in memory will keep using the glibc they already loaded and mapped into their address space. Second -- if it is the same glibc version, it should be backwards compatible. If the major version changes...well, yeah, that can be extra hairy. But its on *WINDOWS* that you can't replace the library out from underneath a program. This is why I'm frustrated -- people are so subconsciously programmed by the MS way, that they believe there is no other.
1: All the new packages are compiled against a new set of system libraries, therefore you need the new set of system libraries. 2: All the old packages are compiled against the old set of system libraries, therefore you need the old set of system libraries.
---- The above is very simplistic and not entirely true. Unless the libraries change major versions, they are likely compatible (more often than not). More recently, SuSE was smarter than you guys seem to think -- they've often shipped a "compat" library, so old glib-linked programs will run with the new glibc. Otherwise 3rd party vendors would have a fit. You can't just "invalidate" all previous applications without causing alot of headache and losing many customers -- why do you think most win98 applications still run on XP w/o change?
3: The new packages will not run with the old set of system libraries, and the old packages will not run with the new set of system
The old package will run on the new-libraries when they are properly configed and installed -- otherwise all the application vendors would throw up their hands and refuse to support SUSE. Does anyone bother to think? You can't just invalidate all previous 3rd party apps -- it kills the market.
4: You can't have both sets of libraries.
This is just plain untrue. If they are different versions of the libraries, then yes you can install both versions. Unix has version numbers on ".so" files since before linux was around.
You have two options:
1: Bit the bullet and fully upgrade the system, while running another system: be it the dvd, or an auxiliary partition.
Or...finish what I'm doing. Seems to be working just fine despite all the naysayers. did ... I only have ~90 packages left out of ~800 total, so I've fewer than 10% of the system still running at 9.3. It doesn't crash. It doesn't die...just keeps on ticking. ...the system is running fine. I've done it this way since 7.x ->8.x ->9.x ->10.x i386(10.2)->x86_64(10.3) (the most challenging of the bunch). But this stuff is not rocket science.
2: Upgrade only some programs, using packages you compiled yourself against the set of libraries in 9.3. You can not use packages from 10.3. If some work, that's the exception.
It's bug when it doesn't work. That's what rpm pre-reqs are for. Do you really think software vendors are going to bother with your platform if you force them to put a new version everytime you upgrade the OS? They (and users) don't want that type of headache. My current package distribution (on the machine I'm doing the manual upgrade on) looks like: 11 (none) 1 SuSE Linux 9.1 (i586) 88 SuSE Linux 9.3 (i586) 1 SuSE Linux 9.3 (i686) 9 openSUSE 10.2 (i586) 670 openSUSE 10.3 (i586) 2 openSUSE 10.3 (i686) (uptime 19 days at this point)... Whether you believe it or not, it works just fine. You make sure the needed libraries are present and off ya go. Contrary to your assertion of mixing packages working by 'chance', the 10.3 nfs server packages refused to work with 10.3 on test systems, so I reverted to the working 10.2. Seems to work fine. The ones that are mostly left are two "problem packages" that I'm not looking forward to touching (bind & samba) and a bunch of interdependent yast programs. The last problem I'm trying to solve in the yast installation is an error of the form: (old, 9.3)rpmnam < Version conflicts with (new, 10.3)rpmnam In that situation, you parse the old rpm-name and version, and look for an updated package in the 10.3 database. If not there, you check the conflicts database to see if the command was obsoleted, if so, add the obsoleting packages to the rpm command name. Then retry the rpm command and see if there are any new errors. I *could*, if sufficiently motivated, do the entire thing without successive runs of RPM, by only using the RPM databases on the system and the sum of them contained in each package in the new dist. But this isn't a *random* process... It's a process guided by the rpm interdependency database. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org