Re: [Cooker] 9.0 -> 9.1 with urpmi - experience
Le Mercredi 26 Mars 2003 20:25, Duncan a écrit : > Of course, getting all the various urpm* guide sites to mention it too > would be nice, but since most of them are user sites... www.urpmi.org aims to be the definitive reference however. -- If such a program has not crashed yet, it is waiting for a critical moment before it crashes. -- Murphy's Computer Laws n°6
Re: [Cooker] 9.0 -> 9.1 with urpmi - experience
On Mon 24 Mar 2003 04:05, Lea Gris posted as excerpted below: > François Pons wrote: > | 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. > > Thank you for providing us with this information. It may be wise to > dispatch this as widely as necessary. Indeed. I'd suggest putting this in the man page. I know that's where I initially learned how to use urpm*, after seeing it mentioned somewhere. Of course, getting all the various urpm* guide sites to mention it too would be nice, but since most of them are user sites... -- Duncan "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
Re: [Cooker] 9.0 -> 9.1 with urpmi - experience
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 François Pons wrote: | 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. | | 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. | | François. Thank you for providing us with this information. It may be wise to dispatch this as widely as necessary. regards - -- ~ Léa Gris () Campagne du ruban texte brut contre les courriels en HTML, /\ contre les pièces jointes Microsoft. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+fuaQiNTO/wgn58kRAlZxAJ9hgRfp6WhXGW2lMnmQozdqB2NGsACgzMU0 i5Kp1Osk2/KFqkuPvySyEeU= =Dn3y -END PGP SIGNATURE-
Re: [Cooker] 9.0 -> 9.1 with urpmi - experience
On Mon 24 Mar 2003 06:07, Adam Williamson posted as excerpted below: > 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 :) Hmm.. Same here.. /var I made pretty small, certainly not large enough to fit an entire CD plus of upgrades in, as I didn't intend to keep mail spools and etc. in it. I've been symlinking it to a subdir of /tmp, since the RPMs themselves have been essentially /tmp appropriate, as volatile temp has been more in order than non-volatile /var. Of course, I may have to rethink that if urpmi gets serious rsync change-only d/l capabilities one of these days. Of course, it's about time to do that anyway, as I really should take off my old and slow 7G hd, repartition the 36G reducing MSWormOS to a skeleton install, just so I can boot to check hardware/driver functionality there, if Linux is giving me problems with something, and to get on the net and d/l a fix if I find my cooker install to be "poached eggs", and then spread some of my Linux data from the currently dedicated 100G drive over to the 36G. Of course, the other way to solve that would be to get a 200G drive, or similar. -- Duncan "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
Re: [Cooker] 9.0 -> 9.1 with urpmi - experience
On Mon, 2003-03-24 at 13:07, Adam Williamson wrote: > > > 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 > > > 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. ERK! replying to myself, sorry. Just to say, obviously my brain wasn't working when I wrote this - of course I meant just "kdebase", not "kdebase-kdm". -- adamw
Re: [Cooker] 9.0 -> 9.1 with urpmi - experience
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 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
Re: [Cooker] 9.0 -> 9.1 with urpmi - experience
Le dim 23/03/2003 à 05:14, Adam Williamson a écrit : > 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). > 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. > 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. 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. François.
Re: [Cooker] 9.0 -> 9.1 with urpmi - experience
Entête en cours de reécriture, merci de patienter en lisant la réponse au mail de Luca Olivetti, à Dimanche 23 Mars 2003 17:08 > Guillaume Rousse wrote: > > etc-update (in contrib) is your friend. > > nice but not enough. > What's missing is the diff between the previous default config and the > user modified config (so that it's easy to spot what the user has > changed), and a diff between the previous default config and the rpmnew > (so it's easy to spot the differences introduced in the config file). and it still display diff for 2 identical configuration file. if toto.cfg.rpmnew is the same as toto.cfg, the rpmnew should be erased. this can happen if you do some weird upgrade liken, and if you use a binary compiled from source. -- Mickaël Scherer
Re: [Cooker] 9.0 -> 9.1 with urpmi - experience
Guillaume Rousse wrote: etc-update (in contrib) is your friend. nice but not enough. What's missing is the diff between the previous default config and the user modified config (so that it's easy to spot what the user has changed), and a diff between the previous default config and the rpmnew (so it's easy to spot the differences introduced in the config file). Bye -- Luca Olivetti Note.- This message reached you today, it may not tomorrow if you are using MAPS or other RBL. They arbitrarily list IP addresses not related in any way to spam, disrupting Internet connectivity. See http://slashdot.org/article.pl?sid=01/05/21/1944247 and http://theory.whirlycott.com/~phil/antispam/rbl-bad/rbl-bad.html pgp0.pgp Description: PGP signature
Re: [Cooker] 9.0 -> 9.1 with urpmi - experience
Le Dimanche 23 Mars 2003 12:24, Michael Scherer a écrit : > Entête en cours de reécriture, merci de patienter en lisant la réponse au > mail de Guillaume Rousse, à Dimanche 23 Mars 2003 12:16 > > > > And, I think that rpm should check before creating rpmnew file, by > > > doing a md5 checksum, to see if the file is not the same. FOr now, it > > > look if the file is in the database and don't touch it if not. > > > > It is current rpm behaviour to check modification of configuration files > > before replacing them. I don't understand what you explain about files > > 'not in database' > > My rpm database was corrupt ( ie was empty :-( ) during the update so, my > /etc/ is full of rpmnew, since a lot of files was not recognized as owned > by a old package. > > If rpm checked with the md5sum, most of them would not be here. rpm check current file md5sum vs md5sum stored in the database. > This is not a big problem, because rpm database corruption should not > occur. And, it give me some bash exercise :-) etc-update (in contrib) is your friend. -- All components become obsolete. -- Murphy's Computer Laws n°8
Re: [Cooker] 9.0 -> 9.1 with urpmi - experience
Entête en cours de reécriture, merci de patienter en lisant la réponse au mail de Guillaume Rousse, à Dimanche 23 Mars 2003 12:16 > > And, I think that rpm should check before creating rpmnew file, by doing > > a md5 checksum, to see if the file is not the same. FOr now, it look if > > the file is in the database and don't touch it if not. > > It is current rpm behaviour to check modification of configuration files > before replacing them. I don't understand what you explain about files 'not > in database' My rpm database was corrupt ( ie was empty :-( ) during the update so, my /etc/ is full of rpmnew, since a lot of files was not recognized as owned by a old package. If rpm checked with the md5sum, most of them would not be here. This is not a big problem, because rpm database corruption should not occur. And, it give me some bash exercise :-) -- Mickaël Scherer
Re: [Cooker] 9.0 -> 9.1 with urpmi - experience
Le Dimanche 23 Mars 2003 11:58, Michael Scherer a écrit : > Why did urpmi insist of downloading all package before installing them ? Cause it is the simplest way to do it. But i agree than extracting the largest subset of package that would fit available size in /var/cache would be better. > And, I think that rpm should check before creating rpmnew file, by doing a > md5 checksum, to see if the file is not the same. FOr now, it look if the > file is in the database and don't touch it if not. It is current rpm behaviour to check modification of configuration files before replacing them. I don't understand what you explain about files 'not in database' -- The speed with which components become obsolete is directly proportional to the price of the component. -- Murphy's Computer Laws n°9
Re: [Cooker] 9.0 -> 9.1 with urpmi - experience
Entête en cours de reécriture, merci de patienter en lisant la réponse au mail de Adam Williamson, à Dimanche 23 Mars 2003 05:14 > Overall, I can broadly say...it worked. You were lucky, i did the same, and, it was a nightmare. Well, not really a nightmare. Since I was a newbie on upgrade with urpmi, i think i have done something wrong. just added the sources for cooker, and urpmi.update -a ; urpmi --auto-select --auto first problem, wget keep doing a connection for each file, and downloading the long listing. So i updated to use curl. curl wasn't able to work, a proxy problem. So, after having done something ( disabling a old proxy conf in urpmi ), I began the update. After 1 hour, /var is full, urpmi stopped, and I discover that my rpm database is corrupt ! ( well, it may be my fault, since i killed some curl process cause of proxy, I may have done a mistake... ) so, I try to rebuild, no way, and now, I have done a script to reinstall all rpm with urpmf , find and rpm -qf. But the computer still run, and, it runs well. So, is there something I missed for the upgrade ? Why did urpmi insist of downloading all package before installing them ? And, I think that rpm should check before creating rpmnew file, by doing a md5 checksum, to see if the file is not the same. FOr now, it look if the file is in the database and don't touch it if not. -- Mickaël Scherer
[Cooker] 9.0 -> 9.1 with urpmi - experience
Well, my Dad runs stable Mandrake releases on his system. He was quite eager to get onto 9.1, so since the .ISOs are delayed we decided to update his system using urpmi with Cooker sources. I took charge of doing this tonight. 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 caused problems itself, though - manually removing the old packages I had to use --nodeps, and it couldn't then install the new packages with urpmi because both curl and wget rely on openssl. So I had to download the new packages with ncftp and manually install them, then download the wget package and manually install it. Further, installing the new openssl packages required the new glibc version, which seemed to cause problems for the 9.0 programs - I couldn't use rpm -Uvh any more, for instance, but fortunately urpmi still worked. This is a bit of a mess that I can see being a problem for anyone trying to update via urpmi. 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. 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 :). -- adamw
