I am sorry that your yum is broken

Submitted by dag on Wed, 2007/11/14 - 00:18

This weekend, after a few weeks of perl updates and fixing our perl SPEC file generator, I broke the perl dependencies and probably upset a few people along the way.

The good news is that we have some new tools for better automating and updating our perl RPM packages and the coming week I hope to finish updating the existing one.

The bad news is that your yum is broken by design. I wish apt was an option, but that possibility looks dimmer and dimmer. (Even though I am still an avid apt user)

It makes no sense that yum breaks because it can not satisfy a dependency. And no, you should not need a plugin to handle this case.

A system that requires a plugin to fix a broken design is bad. And I don't feel responsible for breaking the repository because yum should not bail out on it. Dependencies will break in the future, even with consistent repositories, a combination of repositories may not be consistent and yum should not stop working because of that.

It angers me that after so many years we still struggle with basic problems that have been fixed elsewhere (read: apt).

can you reference anything at all for what you're seeing

I understand the virtue of the rant but you've not even explained what it is that is supposedly broken by design and unless I'm crazy I've not seen this pass across any bug report.

I no longer bother

With all due respect, my feedback often gets discarded, we cannot talk about a dialogue anymore.

closing this as it doesn't really matter anymore.
https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=397

closing - default and expected behavior
https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=417

And these are just the ones that I did report. There have been other cases where feedback has been ignored in the past, so excuse me for not reporting yum problems that my users report to me.

Yum bails out in too many situations like missing dependencies (I heard there were plugins to work around them), yum's output is too verbose and too confusing by default.

Example:

[root@rhun purple-2]# yum install pidgin
Loading "installonlyn" plugin
Setting up Install Process
Setting up repositories
pidgin 100% |=========================| 951 B 00:00
rpmforge 100% |=========================| 1.1 kB 00:00
base 1.1 kB 00:00
updates 100% |=========================| 951 B 00:00
http://mirrors.versaweb.com/centos/5.0/addons/i386/repodata/repomd.xml: [Errno 14] HTTP Error 403: Forbidden
Trying other mirror.
addons 100% |=========================| 951 B 00:00
http://mirror.myriadnetwork.com/centos/5.0/extras/i386/repodata/repomd.xml: [Errno 12] Timeout:
Trying other mirror.
extras 100% |=========================| 1.1 kB 00:00
Reading repository metadata in from local files
primary.xml.gz 100% |=========================| 1.4 MB 00:08
################################################## 5189/5189
Parsing package install arguments
Nothing to do

In this case a simple Package pidgin is already installed and the latest version. would have sufficed and is less confusing. All the other output (by default) is in my opinion useless to the normal user.

Fedora/yum/createrepo (python) developers also tend to use the latest and greatest features of python and this is a major PITA for us mortals who are stuck with older distributions. Getting rid of yum-arch which is still an important tool for up2date and yum users on EL2, EL3 or EL4 was also shortsighted.

The repomd metadata, once believed to be the final metadata format is now being fragmented as well with newer releases of createrepo (that do not build on older distributions) which makes it impossible to generate metadata on other platforms.

Oh well, enough food for another blog article, I guess :-)

so you just want to rant

Let me translate what you've said another way:

"My ideas are not agreed with by the upstream maintainers and they do not do everything I want, when I want it done, that must mean their unresponsive and dumb."

Another way of thinking about it is that they might just not agree with you.

Has it occurred to you that two people can disagree about something without either of them actually being wrong?

Now, about your claims above:
1. the output is also to help the user be able to debug their own problems when things go wrong.
2. the metadata is not, to my knowledge, fragmented at all. There are multiple additional metadata files that are added but the primary/filelists/otherdata files are all the same in all implementations I've seen.
3. The 'already installed' line has been added to the default output in yum 3.2.7 and above
4. yum-arch was removed from yum b/c it confused more people than it helped. They didn't understand that it no longer made the metadata that the version of yum they downloaded used. yum-arch, at least in fedora, is in a separate package. That package should be trivially built on el3 and el4. Not sure about el2 I haven't built anything there in a long time.

-sv

Hey wait, I can play this game too...

Let me explain what you just suggested in another way:

"I expect people to read my brain when I discard feedback without any information and I do not answer bugreports."

and

"And if they come back, I just put the blame on them by having them feel guilty because they don't understand disagreement."

For disagreement you need information. I cannot disagree with your point of view, because you did not give it.

So here goes:

1. That's fine, when someone has a problem. Do you think there are more people that have a problem than people that don't ?

2. Sure, but I cannot generate the newer metadata on an older system, or the older metadata on a newer system. Do I need 2 systems to generate both metadata ? Maybe install a second python ?

3. I consider that a little *too* late, but hey, what is my opinion worth, right ? We're stuck with older yum's until 2014 ? (And no, this is not the first time I brought this particular item up to you...)

4. You could have foreseen that very easily. Dropping the program off the face of the earth is so very Fedora-like. You don't have to think 6 months back or in the future. We don't need it ? Let's drop it... (PS This and other feedback is not only my opinion, lots of people complained or gor confused because you opted to have the program scream that it ws irrelevant)

Maybe explaining some more and listening to other people's arguments would help ? But you discard it.

I have 2 possibilities for my feedback being discarded, either this is a personal problem you have with me, or you are only interested in things that fit a certain agenda.

I thank you for bringing this up on my blog. I feel so much better now...

Ok, ok so what now?

Ok, ok so, not being at all familiar with your new and improved method to access your repository, what do you have now in way of access your mirror of rpm's for RHEL 5,...?

I've just moved on to smart

I left APT/YUM a long time ago. First because YUM was slower than anything (the old header.info mess) and I had found smart to be just better and have an easier interface to work with (that didn't crash as much as apt-shell) and has a VERY nice priority system that is easier to understand than apt's

Currently I'm using APT on a few EL3 systems which are going to be upgraded to EL5 sometime soon (Cent Variety)

I only played with YUM a little on EL5 until I got sick of it and build smart myself while waiting it to show on RPMFORGE (thanks for getting it up ther BTW).

Package Manager: yes or no.

Take a good look at http://www.gobolinux.org/.

They managed the package managers: they do not have it!

Maybe you can write a recipe to read a rpm or a deb package and write the pachage for CEntOS (and others RedHat alike) as it is in GoboLinux.

I think that ALL the problems we have with ALL distros are the package manager they use on their distros.

We really do not need a package manager, since does not matter if you have on, two or 10 copies of a package on your HD.

HD is cheap and my time waiting for a RPM or DEB or whatever is extremelly expensive, since it is not only my work time, it is my LIFE I spend with a package manager.

What we DO need is an Operating System with the basic packages completely separeted, detached, from the rest of the distro.

Python (I prefer OCaml) can be installed by the system in a protected (by the system) area AND ANOTHER copy of python for the rest of the system.

I think GoboLinux is the final cut and the answer we all were waiting for.

I am preparing to move to GL.
I would like to here from you, since you are a great professional on Linux area.

Best regards.