Bug 431854

Created attachment 243285 [details]
bzip2ed latest y2log

May be for 11.2?

Does that mean that the old 11.0 behavior asking if you wish to install more packages has gone for good? This function is not really needed for stable versions but it would be a great help in 11.2 alpha. 

That would have to be done in yast2-packager, not in the package selector widget.

Just to clarify: I completely agree that it makes sense to ask the user if he would like to restart the package selector if there was an error. 

But if everything worked out OK, this is just a nuissance. We had that for so many releases because starting up the package selection was so painfully slow. With recent performance improvements, however, this is no longer the case.

Yes, when everything is OK no popup should be displayed.

Just a plain user (well, from Suse 6.0 that is) I completely disagree, to be honest. It's very handy to have Yast ask if one has to do some more work installing/de-installing packages; specially in cases that one doesn't know beforehand wat has to be installed for a wanted functionality. As a matter of fact, I tend to never close softwaremanagement, wich is impossible with the behaviour introduced in 11.1.

So please, please, give me back the pop-up!

I also request the feature be reinstated.

Reasons:

 - Yes, package selection is faster, but not lightningly fast (25 seconds in my system to start).
 - It is not a nuisance if everything was Ok, it is a reassurance that everything was indeed ok. When the windows disappears, I'm always doubtful if it crashed or succeeded.
 - Programs exiting silently on linux is a good thing... on the console. In the console you can review what happened. In a graphical interface it is not a good idea.
  - Being asked if I want to install more things is helpful. I often do: install something, try, remove, install another...

And not only for the betas, also for the stable distro.

At worst, make this behaviour configurable.

As Dave stated on factory mail list, one click on icon in YaST Control Center,
or in popup window is the same action, but closing the window without any message appears more as a crash. We had before users confused with such behavior.

Going back to software selection screen would be action that I expect if everything is OK. I started there, before click on "Accept" button, and if there is no error going back to that screen would be logical end of successfull action. Installing few pieces of software doesn't mean that I'm done. 

If user needs no more changes he/she can always close the window, or press "Cancel". 

BTW, "Accept" can be changed to "OK". The meaning is the same, but "OK" is much more common to confirm and apply changes. 

Well, to make it configurable would be a very acceptable solution to me.

So, if that could be arranged, thanks!

Yes, I want to be able to see some feedback that indicates the update/install I started before leaving work completed without error so I don't have to go digging through logs in the morning just to find out. Seems like such a simple thing.

I used to be annoyed by the "Install More?" dialog until I stopped and asked myself "Well -- How would you know it went OK?" if the dialog wasn't there. I started liking it after that.

Either the dialog or some other type of feedback is fine. Since 11.0, the 20 minute refresh problem is gone so either new dialog or "Install More?" is fine with me, but I definitely want the feedback.

The current behaviour looks very like an unintended coding error as I cannot see any sane reasoning for the change. It's not the way any other OS on the planet works and it definitely introduces an unwarranted disruption of your workflow.
The long established way was never a subject of complaint because it was logical - philosophically, you close up shop when you are finally done for the day, not after serving one customer and having to reopen when another one knocks on the door.

Probably the best would be to leave one line below those few that report 
script execution, telling user that all was OK, and 2 buttons "Continue" 
and "End" in the bottom right corner. The same functionality as popup, but 
consistent look and feel. 

Popup frame depends on used window manager and can spoil esthetics, like all poppus during installation do. Beautiful Beta5 installer screens and fvwm2 square popups don't fit togeather.

I would like to add that I much prefer the 11.0 behavior of asking if I'm done or not yet.

Rather than having a popup dialog, it'd be more streamlined to allow a checkbox to be selected, which is toggled.  "Auto Exit"

This could work like the Autocheck feature.

The System Configuration log screen seems pointless, except to show activity, I can't remember it showing anything interesting.  A log screen, which showed packages changes, config done, with more detail on errors might have more value.

For instance -

Install Bloaty-Game
  dependencies installed
      libslayer
      libFrag

Would let someone see what packages to uninstall if they decide they don't need it, especially if the log file was viewable later.

*** Bug 466569 has been marked as a duplicate of this bug. ***

*** Bug 462352 has been marked as a duplicate of this bug. ***

The installation summary dialog has been implemented in yast2-packager-2.18.2 and yast2-2.18.1. (factory, openSUSE-11.2)

Closing as fixed

Running yast2-packager-2.18.2-1.6 and yast2-2.18.4-1.3, just had a few failed package downloads which I had to skip and apart from the reboot for new kernel message yast qt software manager simply closed. Will upload logs later.

Created attachment 269900 [details]
y2log bzipped

I deliberately caused 504 error by restarting squid during download, the package which was skipped is glibc-i18ndata-2.9-10.5.x86_64.rpm

If a package is not installed along with others, it may cause an unstable system. In this case yast should not exit at all and remain in memory. The number one reason for a package being skipped is due to a repo update after the last refresh therefore the repos need to be refreshed and the system verified and whatever new dependencies arise have to be satisfied. This will be much easier with a download first then install and in this case no harm will come to the system but in the meantime please honour the second last line in /etc/sysconfig/yast :-
# The summary dialog is always displayed when an installation error has occured.
This is the most important case for a dialog box, especialy when using the factory repo or even the kde42 one which first alerted me to this bug.

At first the error occurred:

2009-02-04 10:36:53 <1> Arbuthnot(8477) [YCP] PackageCallbacks.ycp:1931 Downloading http://download.opensuse.org/factory/repo/oss/suse/x86_64/glibc-i18ndata-2.9-10.5.x86_64.rpm to /var/adm/mount/AP_0x00000001/suse/x86_64/glibc-i18ndata-2.9-10.5.x86_64.rpm
2009-02-04 10:36:53 <3> Arbuthnot(8477) [zypp] MediaCurl.cc(doGetFileCopy):1276 curl error: 22: The requested URL returned error: 504, temp file size 0 byte.

Then user pressed [Skip]:

2009-02-04 10:37:08 <1> Arbuthnot(8477) [YCP] PackageCallbacks.ycp:1040 MediaChange `skip
2009-02-04 10:37:08 <1> Arbuthnot(8477) [zypp] MediaSetAccess.cc(provideFileInternal):341 ProvideFile exception caught, callback answer: 2
2009-02-04 10:37:08 <1> Arbuthnot(8477) [zypp++] MediaSetAccess.cc(provideFileInternal):352 Skipping
2009-02-04 10:37:08 <5> Arbuthnot(8477) [zypp] Exception.cc(log):133 MediaSetAccess.cc(provideFileInternal):357 THROW:    MediaSetAccess.cc(provideFileInternal):357: SKIP request: User-requested skipping of a file

The package was skipped and the other packages were downloaded and installed:

2009-02-04 10:37:08 <2> Arbuthnot(8477) [zypp] TargetImpl.cc(commit):816 Skipping package (23844)glibc-i18ndata-2.9-10.5.x86_64
(factory) in commit
2009-02-04 10:37:08 <1> Arbuthnot(8477) [zypp] PackageProvider.cc(providePackage):96 provide Package (23840)glibc-32bit-2.9-10.
5.x86_64(factory)

The problem is here:

2009-02-04 10:48:14 <1> Arbuthnot(8477) [zypp] ZYppImpl.cc(commit):151 Commit (CommitPolicy( syncPoolAfterCommit )) returned: CommitResult 17 (errors 0, remaining 0, srcremaining 0)

The commit result does not contain any error, Yast gets OK status and therefore no summary is displayed.

Reassigning to libzypp team...

bug #462352 (has been considered duplicate but) refer to "always", this one refer only to "fail", and anyway has not fixed yet in 11.2 milestone 1.. news?

I can confirm, that installation summary isn´t appeared in Mileston1 and software management is closed.

Still the same in Milestone2. Not fixed yet.

    In addition, After updating to factory Yast2, I am surprised to find there is no "Skip" option to choose in the event of a failed package during install. Today, attempting an update, all "cairo" packages failed due to freetype errors. Once the package failed, the only options were to:

    "Ignore" "Abort" "Retry"

    All I wanted to do was "skip" the failed package and continue installing the rest. Where has the "skip" option gone??

    In this case "ignore" is equivalent to "ignore" the error and "force" the install. A very very bad thing. Choosing ignore generates a prompt warning that Choosing Ignore can Lead to a Broken system.

Abort -- is not what I need to do

Retry -- simply fails and gives the same error

    Something is very wrong in the choices presented to the user in the event there is a problem with one of the packages. Currently when you encounter a package error you have two options (1) force the installation of a broken package and risk a broken system or (2) abort the entire update and start over wasting all the time you spent resolving dependencies and protecting packages before starting the install.

    Let me know if you need more info. Thanks.

(In reply to comment #27)
>     In addition, After updating to factory Yast2, I am surprised to find there
> is no "Skip" option to choose in the event of a failed package during install.
> Today, attempting an update, all "cairo" packages failed due to freetype
> errors. Once the package failed, the only options were to:
> 
>     "Ignore" "Abort" "Retry"

David, this is unrelated to the original problem, please open a new separate bug report for this (assign it to me and do not forget to attach the Yast logs).

not fixed yet on M7..

will that fixed??

If it is thought that nothing like for instance, a major glibc update can go wrong because it wasn't available, then this bug isn't major but every new feature buries this bug deeper into the installation system. What is libzypp going to report if download all before install fails on one package, is the solver going to be run again?
Zypper also has this problem not just yast, in this case it's only one package which isn't a problem it could be satsolver-tools in an installation system update and zypper verify will no longer be available because satsolver-tools didn't update :-
 # zypper -v in whois
Verbosity: 1
Non-option program arguments: 'whois'
Initializing Target
Loading repository data...
Reading installed packages...
Force resolution: Yes
Resolving package dependencies...
Force resolution: Yes

The following package is going to be upgraded:
  whois  4.7.33-2.1 -> 4.7.36-1.3


1 package to upgrade.
Overall download size: 58.0 KiB. After the operation, additional 4.0 KiB will be used.
Continue? [y/n/?] (y):
committing
Retrieving package whois-4.7.36-1.3.x86_64 (1/1), 58.0 KiB (179.0 KiB unpacked)
Retrieving: media [error]
Media source 'http://download.opensuse.org/factory/repo/oss/' does not contain the desired medium

Abort, retry, ignore? [a/r/i/?] (a): r
Retrieving: whois-4.7.36-1.3.x86_64.rpm [error]
Failed to download ./suse/x86_64/whois-4.7.36-1.3.x86_64.rpm from http://download.opensuse.org/factory/repo/oss/
Abort, retry, ignore? [a/r/i/?] (a): i
Warning: You have chosen to ignore a problem with download or installation of a package which might lead to broken dependencies of other packages. It is recommended to run 'zypper verify' after the operation has finished.
committingCommitResult 1 (errors 0, remaining 0, srcremaining 0)

At least zypper outputs a warning but why doesn't it run verify anyway instead of displaying the warning and giving the user a choice? Most probably because libzypp outputs :-
(errors 0, when there is an error, a package selected as part of the installation wasn't downloaded for some reason, the installation has errors.
What happens if the internet stops halfway through a zypper dup?

Is this still an issue with openSUSE 11.3 ?

Michael? (ma)

I've been a bit tied up lately and I'm still running factory from the 11.3 release time. The download in advance function effectively solves this bug with zypper but if it isn't enabled I suspect, without actually testing, that this bug is still there. I'm also not sure atm what yast does when a package fails to download with download in advance enabled. I'll check this when I change to 11.3 in the next couple of days.

You're right, the ZYppCommitResult is not correct. Even with download in advance, the error list (which is what zypper checks) is empty. I'll fix it.

fixed in libzypp-6.33.4 (11.2), -7.9.3 (11.3) and -8.1.2 (factory)

The SWAMPID for this issue is 37855.
This issue was rated as important.
Please submit fixed packages until 2010-12-24.
Also create a patchinfo file using this link:
https://swamp.suse.de/webswamp/wf/37855

Update released for: libsatsolver, libsatsolver-debuginfo, libsatsolver-debugsource, libsatsolver-demo, libsatsolver-devel, libzypp, libzypp-debuginfo, libzypp-debugsource, libzypp-devel, perl-satsolver, python-satsolver, ruby-satsolver, satsolver-tools, zypper, zypper-debuginfo, zypper-debugsource
Products:
SLE-DEBUGINFO 11-SP1 (i386, ia64, ppc64, s390x, x86_64)
SLE-DESKTOP 11-SP1 (i386, x86_64)
SLE-SDK 11-SP1 (i386, ia64, ppc64, s390x, x86_64)
SLE-SERVER 11-SP1 (i386, ia64, ppc64, s390x, x86_64)
SLES4VMWARE 11-SP1 (i386, x86_64)

Update released for: libsatsolver, libsatsolver-debugsource, libsatsolver-demo, libsatsolver-demo-debuginfo, libsatsolver-devel, libsatsolver-devel-debuginfo, libzypp, libzypp-debuginfo, libzypp-debugsource, libzypp-devel, perl-satsolver, perl-satsolver-debuginfo, python-satsolver, python-satsolver-debuginfo, ruby-satsolver, ruby-satsolver-debuginfo, satsolver-tools, satsolver-tools-debuginfo, zypper, zypper-debuginfo, zypper-debugsource
Products:
openSUSE 11.2 (debug, i586, x86_64)