Bug 215445

Created attachment 102762 [details]
bug215445.tar.bz2

Indeed, it doesn't work. Tested with:

yast2-packager-2.13.157-2
yast2-pkg-bindings-2.13.100-4

Bug 181658 claims to have this fixed in yast2-pkg-bindings-2.13.100 and yast2-packager-2.13.155, but it's obviously not true.

I simulated a broken repository, and this is the result - exactly the same as before the fix:

2006-10-27 03:08:27 <5> linux-lebr(21194) [base] Exception.cc(log):94 PackageProvider.cc(providePackage):91 RETHROW:  SourceProvideFile.cc(provideFile):135: File /usr/src/packages/RPMS/i586/C-1-1.i586.rpm fails integrity check. Expected: [sha1-ca840e86b95bee699e38928e28a20761389b97e2] Got: [sha1-da39a3ee5e6b4b0d3255bfef95601890afd80709]
2006-10-27 03:08:27 <3> linux-lebr(21194) [wfm] Package.cc(PkgCommit):2153 Pkg::Commit has failed: ZYpp::commit has failed
2006-10-27 03:08:27 <3> linux-lebr(21194) [YCP] PackageInstallation.ycp:154 Bad media number 0

It stops at that point and omits all the dependent packages.

I _really_ hope that this is not a feature, because it will break installations as it did with 10.1.

(And no, I did not click "abort", not even "maybe")

after the first 'skip' yast shows a popup 'finishing installation', then yast quits.

clients/inst_rpmcopy.ycp:840 Called YaST client returned: `abort
clients/inst_system_analysis.ycp:457 Called YaST client returned: `finish
clients/installation_worker.ycp:432 ProductControl::Run() returned `next
clients/installation_worker.ycp:530 Pkg Builtin called: SourceFinishAll

Hmm, I seems that the installation was really aborted...

Raising to Blocker because I already know that this will - again - break installations as it did with 10.1 already.

It's reproducible in the following way:

- Create a YUM repo with A depending on B, B depending on C etc., until G
- Modify C after the metadata have been generated, to simulate a read error
- Use sw_single, select A for installation, it will pull in all dependencies
- Do the installation. It will install G, F, E, and D. As soon as it tries to install C, it will inform you about the read error.
- Select IGNORE. But what it will actually do is: ABORT.

Expected result: IGNORE means IGNORE, so it should go on with B and A.

Actual result: IGNORE is taken as ABORT, the installation is still completely cancelled because of one failed package, and it does not even run SuSEconfig afterwards. During a "real" system installation or upgrade, it would probably even leave the hard disk in a mess etc.

It seems that the fix of bug 181658 just doesn't work. This is unfixable after the release because it breaks initial installation => Blocker

Created attachment 102863 [details]
YaST2 logfiles

Created attachment 102864 [details]
Testing material

Install "A" from here to reproduce (or even use it as an AddOn-source during installation to see how it breaks the entire installation)

We sat down with Michael to track down this bug. It is not easy to fix due to some broken provideFile semantics.

provideFile, offers the user to abort, retry and ignore, without having any semantics for those actions.

Anyway, we found a bug where the context information was lost in a exception catch, fixing this makes commit finish the installation.

Note, inmediately after skiping a package the rest fail due to dependencies, so they are retried with --nodeps. There is no progress bar anymore, and you have to wait till commit tries to do whatever it can, with no guarantees of a broken system.

As Michael said, never expect things to finish if you skip glibc.
Fix in zypp r4469.

Thanks Andreas for the quality of the bugreport, especially your testing material.