Today the sluices were opened on Leap 16.0 and more then 170 updates were available on my system.
Used Myrlyn to do the update. Somewhere half way during the installation phase there was a package that did not install correctly (something ending on 32bit). I cancellded that install and Myrlyn went on installing the rest. But that package’s name kept displayed in the “Doing” list (along with the others passing after another). At the end it was still in the list and the only thing I could do (or missed I something) was hitting the “Cancel” button, which stopped Myrlyn.
Two questions:
Shouldn’t there be away to finish Myrlyn in a “normal” way here?
What about post installation scripts, I saw no mentioning of them being executed. Are they executed?
Probably if you simply restart the whole dist-upgrade, it will simply work.
This might be a case when a package was not available on the server in the version that the repo metadata described. This happens very rarely. Especially with a non-rolling distro like Leap, the update on the server side should be consistent and atomic; but sh*t happens. It might also have been an incomplete sync of the mirror that you used.
Are you sure the problem happened during installation of that package, not during download? The way libzypp is set up is usually that it does all downloads first, and only when that was successful, it installs all the downloaded packages one by one.
If one package can’t be downloaded, and you skip it, it will still install all the others, and AFAIK execute all the post-transaction scripts for them. But there might simply not be any that take long enough for you to see the visual feedback for it.
Of course you can always check the logs in /tmp/myrlyn-root/, both myrlyn.log and zypp.log, or the older versions from previous Myrlyn invocations ending in -00.log, -01.log, -02.log.
This is Leap 16.0, thus it was the “Package Update” button (thus zypper dup). And I did a retry, nothing to be done.
I am very sure.
That is what I hope for. But there was a Kernel involved. I though, but am not sure, that then an rebuild of initrd should be done and that takes time.
The thing is of course that it always can happen that one package install has a problem and offers a retry, a cancel or a cancel all. I choose the cancel and indeed all the others were then installed as I hoped for. But there seems to be no contingency for this, it ens with only a Cancel button available. And in the middle column, lower part that one package was still there.
Maybe I did not wait long enough.
As a Kernel update was installed, I did a boot. And as /tmp is a tmpfs, I do not think looking there is of much use.
Also I have no idea what I should look for.
I look in Myrlyn > Extras > Show history. There I think I can identify the package involved glibc-gconv-modules-extra-32bit. It shows as installed (+).
But again, this topic is not about the problem with the package, it is about how Myrlyn recovers if one answers with “cancel the installation of this packege”.
I will now try another system and see ig I get the same result.
I now updated the other system in the same way. All installed flawlessly and thus no re-creation of the problem
I did now see the post installation remark in the Doing field.
On the package: I checked, but that package, nor any other *32bit is installed. That makes me wondering if I can remove them from the first system. That system was installed December 2016, thus it can have some leftovers.
I do understand why you go off-topic. I more or less do the same. But OTOH I stress several times above that the subject of this topic is the fact that Myrlyn IMHO does not act correct on the Cancel answer to the error. It keeps that package installation in it’s Doing list, and at the end there is no way to finish Myrlyn with the Finish button.
That “Cancel” answer goes straight to libzypp: Everything on the transactions page is done in some libzypp callback. Some of those expect an return value that corresponds directly to a user interaction like this error popup. It’s libzypp that decides how to continue from here.
One way or the other, when one package of many that are part of a transaction cannot be installed because of an error, the general status of the system is very much undefined: Was that failing package a hard requirement for any of the other packages that were also part of the transaction? If that’s the case, what will be the effect of the failure? What part of the system will stop working now? Some of the packages are already installed, and this one is not. There is no easy rollback in this situation.
You may get lucky, and it may not affect you much. But one way or the other, this is very much a worst case scenario with no easy way out.
I am fully aware that this is a situation that does not happen too often. Thus my idea is that in creating Myrlyn it is not something that can easily be foreseen or tested. It is one of those things that happen in daily life and you never have thought of.
Thus I thought to bring it to attention of those (well in fact @shundhammer ) who may be interested and maybe code some improvement. If the latter is not the case then I guess we will live with this.
This code is not particularly pretty; it’s the interface between Myrlyn’s Qt part and libzypp that is based largely on the C++ Boost libs that have their very own design philosophy. And, since this is an event-driven C++ Qt program, it’s also where Qt signals and slots are involved.
One major problem here is that both Qt and libzypp want to live in the application’s main thread, so multithreading would break that rule for one or the other part.
And since Qt’s slots (the functions that are called when a Qt signal is received) can’t return a value, so the value needs to be stored in some other place, hence that sendReply() function. But the sendReyply( AbortReply ) call here is just a well-defined initial value that the receiver of sendPkgInstallError() will put there; this is the function that opens the “Abort”, “Retry”, “Cancel” popup.
