Issues with yum

Przemek Klosowski przemek.klosowski at nist.gov
Tue Feb 28 17:50:23 UTC 2012


On 02/27/2012 07:04 AM, Josh Boyer wrote:
> On Mon, Feb 27, 2012 at 1:44 AM, elison.niven at gmail.com:
>> I forgot to add: 8) Yum cannot use an iso image as a repo without
>> mounting it. Yast in suse allows to directly use iso images as
>> repos.
>
> You also forgot to add:
>
> 1) A proposed alternative 2) Patches to fix any of the issues you
> pointed out 3) Anything constructive at all in your ramblings.
>
> Seriously, if you want yum replaced with something then you need to
> show up with an alternate proposal, how it would work, and people
> willing to do that work.  Without those things, this is at best going
> to be ignored and at works just turn into a huge "ME TOO" thread that
> still winds up generating no change.

I love yum. I have been using it on dozens of systems for probably 
something like 100 system-years. Normally it's rock-solid, but when it 
breaks it is something to behold. I had a couple of failures over the 
years, and it just so happens that the system I write this on has a 
major problem when out of the blue yum just collapsed in a heap:

https://bugzilla.redhat.com/show_bug.cgi?id=796382

Things can happen---I am OK with that. What worries me more is that yum 
became a little baroque and non-transparent. There is a litany of 
remedies for yum problems:

yum-complete-transaction
rpm --rebuilddb
yum clean all
package-cleanup (--problems/orphans/dupes/leaves)

While I have a general understanding of how yum works, and one or more 
of the above always got me out of trouble in the past, this time they 
didn't help and I don't know what to do next: which tools to use, what 
to look for. Yum-utils has 23 separate executables and 18 manpages that 
list a bewildering variety of options and subcommands---intimidating 
complexity, which may also be reflected in increasing yum run times for 
routine actions like queries and updates.

Of course it's not reasonable to throw yum out and start from scratch.
Given that it almost always works very well, perhaps it's even 
reasonable to conclude that it should be left alone. Even if we agree 
that something should be done, which of the following ideas are worth 
pursuing:

  * better diagnostic tools
  * more visibility into the yum data and internals
  * some refactoring
  * documentation for debugging problems

Re-reading what I wrote, I realize that it's not very constructive, as I 
don't know what is the right thing to do to improve yum, much less how 
to do it. I just want to raise the issues for discussion.


More information about the devel mailing list