Was [Yum] Defining failure... now minimalist yum documentation

[David Potter]

I'm sorry Seth, I should have started a separate thread reflecting on 
the minimalist yum documentation and the importance of human-parsable 
output.
Let me re-phrase this.

1) I think that failure begins when the end user is not given enough output 
information to continue the process to success.

2) If/when I try to upgrade a package and yum regretfully declines with a series of dependency issues, I would expect useful output, so that even though yum has admitted that it can't figure it out, that it would offer some idea of where to begin.

yum will tell me that package A depends on package B, C, and D

But, I'm never sure if yum knows that package B depends on package i, and ii

...or if yum knows that package ii depends on package 1, 2, and 3

...or if yum knows that the problem is actually package 2 and that resolving that issue would solve all the problems.

Should I start with the error at the top of the list? I'm not clear if yum is actually sorting the output or reporting the dependency errors in some random order.

------

I'm not sure if changing the error level will actually answer any of these questions.


"Read the FAQ" and  "Try uninstalling the offending package(s)... and re-installing them later" become routine answers  ...the tool is very blunt. Those answers are 15-20 years out of date...! While FAQs may list the "Questions". in most cases they do not actually provide the "Answer" that is needed.


I would once again refer you to the Exim documentation. 


seth vidal wrote:

>On Sat, 2006-03-04 at 10:02 -0400, David Potter wrote:
>  
>
>>Hi Seth,
>>
>>I think the failure begins when the end user is not given enough output 
>>information to continue the process to success.    
>>
>
>He's not talking about user output in the mail you quoted below. He's
>talking about scriptable-output. More important machine-parsable output.
>
>
>
>  
>
>>If the software interface/output and documentation require a third 
>>degree black belt system administrator to use the product effectively - 
>>and the product is in the hands of individuals with all levels of 
>>(non)experience then failure/frustration is built in.
>>    
>>
>
>I don't understand where this is coming from.
>
>
>
>  
>
>>When "Read the FAQ" and  "Try uninstalling the offending package(s)... 
>>and re-installing them later" become routine answers  ...the tool is 
>>very blunt. Those answers are 15-20 years out of date...! While FAQs may 
>>list the "Questions". in most cases they do not actually provide the 
>>"Answer" that is needed.
>>    
>>
>
>Again, what problem is it that you're complaining about here?
>
>We'll gladly accept additions to the docs and/or the faq. The faq is in
>a wiki and Greg can give you access to it if you have some good changes
>to make.
>
>  
>
>>I just realized how good the documentation for Exim actually is...  how 
>>do you suppose they managed that?
>>    
>>
>
>Again, I'm getting a very angry tone from you in this email and I don't
>understand why.
>
>-sv
>
>
>_______________________________________________
>Yum mailing list
>Yum at lists.dulug.duke.edu
>https://lists.dulug.duke.edu/mailman/listinfo/yum
>
>  
>