Comment # 7 on bug 1158478 from William Brown

(In reply to Thorsten Kukuk from comment #6)
> (In reply to William Brown from comment #4)
> > (In reply to Thorsten Kukuk from comment #3)
> > > 1. of course the log files do exist and are available in the system, they
> > > are not deleted. And if you want to have a shell, use the option to start a
> > > shell for debugging. Your claims in this regard are wrong.
> > 
> > But the shell won't be in the environment where the "error" happened, it
> > will be a new snapshot yes? 
> 
> If you call the same command again with the shell option, it will be the
> same snapshot.

That's not clear as a 'user experience', and should be indicated that this
behaviour does exist. An important aspect of human psychology and interaction
is discoverability, making things in a UI able to be found. So I would suggest:

HINT: To access the environment where the error occured, run
'transactional-update shell'

This makes it clear and known to people that this feature exists - I certainly
had no idea until you just told me then, which likely means no one else knows
either. In other words, if people don't know it exists, does the feature exist
at all?  

> 
> > > 2. zypper is giving you all informations to solve the problem. Instead of
> > > pasting the long output, you should have read it.
> > > 
> > > man zypper -> you try to install a package which does not exist, and zypper
> > > is even telling you that.
> > 
> > gdb suggested this command to install the debug info, so there is something
> > gdb knows about these packages that doesn't line up when zypper attempts the
> > download then. I'm just doing what the system is telling me here. 
> 
> And zypper is telling you, that a package you want to install does not exist
> and quits with an error code.
> 
> > For the record, I actually totally missed that error on  multiple reads
> > because there is so much information overload, and the error condition is
> > listed *early* in the process, rather than being declared at the end.
> 
> The end contains a clear statement: zypper exits with an error code and the
> error code is mentioned. Exactly what you did request is printed at the end.

Error codes don't communicate what happened, because I'm not a computer :(

> 
> > So I think there are some genuine improvements to be made here for this.
> 
> If you read the the error code and what it means, you know for what you have
> to search in the output.
> The experience is: overlading the end with too much informatons does not
> help, there will be exact the same bug reports as yours, as people don't
> read as they claims it's too much informations.

I'm not suggesting that you "overload" as much as "refine" *where* the error
information is to improve visibility and locality of that. Because the error
message was in the first 10% of the output, people will not be looking there
(and even if they are, the error lacks distinguishing markers to prompt that
it's there). 

These bug reports come from people like me because the user interaction of the
experience could be improved - rather than looking at the symptom (the
existence of the error, the bug report), you should be asking why someone with
a lot of experience was able to (rather easily) overlook this error and raise a
false bug - this implies to me that a communication and user interaction
problem exists between the tool and the user which is causing them to overlook
things. 

Which is why I will suggest again that the error messages are:

* defined as "error" rather than just a "not found" with no identification that
it's the cause of the error.
* That "errors" are collected to a single, localised location at the end of the
output to aid isolation of the issue
* Communication about investigative steps and features that exist should also
be communicated

I believe as already mentioned, the output below already greatly would improve
the "experience"

...
Lots of output goes here
...
(54/54) Installing: liblzma5-debuginfo-5.2.4-4.3.x86_64 [............done]
Installation has completed with error.
ERROR: Package 'libsvrcore0-debuginfo-1.4.2.4~git0.c881f6ec0-82.1.x86_64' not
found.
ERROR: zypper install on /tmp/tmp.XXVSzekuha failed with exit code 104!
HINT: To access the environment where the error occured, run
'transactional-update shell'
Removing snapshot #8...
Removing overlay directory /var/lib/overlay/8...
transactional-update finished

If the output looked like that, I would never have reported this bug at all
because I would have been given the information needed and the agency and tools
to know how to investigate.