On Mon, 2003-03-24 at 10:58, François Pons wrote: > > Overall, I can broadly say...it worked. Good marks for that :). But, > > there were some gotchas along the way. First of all there was rather an > > annoying problem with openSSL. When I just did an --auto-select, it > > failed due to missing "openssl-devel". I *think* the problem is the 0.96 > > (9.0) and 0.97 (9.1) packages don't work well together, and the > > --auto-select was just planning on removing the 0.96 packages (or at > > least the devel package) without updating to the 0.97 packages. My > > workaround was to download and install the 0.97 packages manually. This > > Since urpmi is experiencing big improvement since 9.0, it was necessary > to upgrade at least before urpmi (using updates or unsupported) before > doing the auto-select itself. For the 9.1 this is still the case as lot > of fixes have been done for newer urpmi (so small glitches using old > urpmi may appear on some case which is problably the case using > openssl-devel).
Aha, so you think if I'd updated to 9.1's urpmi and used that to do the --auto-select it would have been able to update openssl 0.96 to 0.97 properly? Sounds possible, no 9.0 systems left to test it though. Sorry. > > Secondly, urpmi is still not quite good enough for doing a > > between-versions upgrade entirely automatically, because of the problem > > of adding new packages. It installed several config files which expected > > the Galaxy theme packages, but of course it didn't install these, I had > > to do it manually. I also manually installed the zcip and tmdns > > packages, because it seems these are necessary for 9.1 machines to work > > as simple network clients - if you try and set up a system with > > drakconnect without these packages installed, it tries to install them > > (which obviously doesn't work if you only have network sources :>). If > > using urpmi to update is to become a recommended path, as I believe some > > people have discussed, I propose it needs some kind of way of taking > > into account "highly recommended" new packages in the new version like > > this. > > All of this is config files handling (which is not done by urpmi) and > media management (for avoiding network usage by drakconnect) which need > doing a little to help it. Yes, I know this all isn't strictly urpmi's job. It just strikes me as an area urpmi could get some neat new features to help with upgrades. Someone's already suggested a "suggested packages" feature, perhaps we could implement this somehow, and for instance kdebase could "suggest" galaxy-kde, which would help upgrades. I guess how this would work would go: urpmi kdebase-kdm <normal urpmi stuff> Package kdebase-kdm suggests package galaxy-kde. Suggested packages are not required but may provide useful or recommended features. Install galaxy-kde? (Y/n) Or something like that, anyway. :). It's an idea. > > Overall, though, I was very impressed - after I worked around these > > niggles, it happily updated the entire distribution (over 600 packages). > > I tweaked the surprisingly few config files that installed as .rpmnew, > > installed the new Cooker kernel, rebooted and there was 9.1, in all its > > glory! Good stuff, it's nice that this pretty much works now :). > > It will be effectively better when it upgrades smootly correctly, there > will be new features for next urpmi which will be smaller transaction, > allowing /var not to become full for upgrading entire distribution. Yes, that was a problem too, but I know that's known so I didn't mention it. I just used my standard workaround...make /var/cache/urpmi/rpms a symlink from a bigger partition :) > Doing updates of urpmi will also help this process to be taken into > account, else it is generally necessary to just "urpmi urpmi" in order > to update urpmi first before updating everything else. Thanks Francois! This is really close to usable now, hopefully it will be entirely usable for 9.2 and we can recommend debian-style upgrades for people :) -- adamw
