Mailinglist Archive: opensuse-factory (765 mails)

< Previous Next >
Re: [opensuse-factory] upgrade packaging not statically built
On 2017-11-14 10:58, martin@xxxxxxxxxxx wrote:
On Mon, 2017-11-13 at 15:13 +0100, Carlos E. R. wrote:
El 2017-11-13 a las 15:04 +0100, martin@xxxxxxxxxxx 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)

< Previous Next >
Follow Ups