On 2017-11-14 10:58, martin@pluskal.org wrote:
On Mon, 2017-11-13 at 15:13 +0100, Carlos E. R. wrote:
El 2017-11-13 a las 15:04 +0100, martin@pluskal.org escribió:
On Sun, 2017-11-12 at 23:34 -0500, Felix Miata wrote:
Simon Lees composed on 2017-11-13 14:04 (UTC+1030):
Felix Miata wrote:
Basil Chupin composed on 12 Nov 2017 09:01:45 (+1100): > Felix Miata wrote:
I thought I was emulating this urpmi safety feature via an emulating script. This was the first time it failed me after too many years to remember of working as expected with distribution releases, Factory, and TW.
Why it makes sense is pretty simple, bad stuff happens,
Hi
It seems that bad stuff that happened here is triggered somewhere between chair and display.
Also note that for regulary maintained releases, zypper patch will update package management stack (zypper, libzypp, rpm) befor installing other updates. This does not make sense for dist upgrade where exactly stuff that happened to you would happen - but hey I guess you know better then developers of distribution.
But "zypper dup" is the reccomended method to upgrade from, say, Leap 42.3 to 15.0. It is supposed to work out of the box.
And "zypper dup" works - installing zypper from Leap 15 on Leap 42.3 does not work - my understatnding from boo#1067737 and from current discussion is that breakage is not result of upgrading while using zypper but consequence of user meddling with upgrade process and trying to use binary from future release on old one.
Ah! This is an interesting point. One of the "recommended" procedures to do a distribution upgrade is to do (method (a)): zypper patch change repos zypper update zypper rpm zypper dup --download-in-advance zypper dup The idea is to avoid problems with zypper itself during the upgrade. You say that doing that will cause zypper to fail because it will use incompatible binaries with the existing libraries from the existing system. The "zypper patch" phase of the existing system should be enough, because the last published patches to that distribution will be made precisely to avoid problems with zypper during the upgrade, and thus installing the next zypper version is not necessary (say, method (b)). I find the issue interesting. :-) I see points in both strategies. I see a problem. Assume method b. During the "zypper dup" at some point zypper, rpm, and all dependencies will be updated. All loaded libraries will remain loaded and working, so the process should continue with the "old" libraries. Ok, good. What happens if for some reason the process crashes (it does happen now and then), and the resulting "zypper stack" on restart is half upgraded, inconsistent? I suggest that zypper should be aware of this, and upgrade itself and all needed libraries as one operation somehow. I'm thinking of this or similar: ## DownloadInHeaps, Similar to DownloadInAdvance, but try to split ## the transaction into heaps, where at the end of ## each heap a consistent system state is reached. (/etc/zypp/zypp.conf). Another problem. People may try to upgrade from 42.3 to 15.0 right now, before 15.0 is finished (to try it and the upgrade process), but the "final patch" to zypper in 42.3 has not been published yet. Thus this upgrade method (b) may (or is it might?) not work, right? So people may think that method (a) is more appropriate during this phase. I think this is Felix reasoning. Just thinking! Not trying to criticize anybody ;-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)