![[lang]](/images/eye.png)
I still hate yum’s default action on problem packages |
2007-08-29
|
This is one of those things where I just don't understand the arguments for the opposite view.
Here's what yum does that so annoys me.
If you ask it to upgrade, and there's even one simple problem, it doesn't upgrade anything. The problem could be "I can't download this package I want". It could be "there's something wrong with my metadata". Or it could be "I don't know the key for this package".
Me, I come from a belief that things will fail and you're better off handling the failure cases if you want to make your user happy.
So today it's biting me again and I've decided to just dump it on the intarweb every time it bites me and it just doesn't make sense to me.
# yum upgrade
Setting up Upgrade Process
Resolving Dependencies
--> Running transaction check
---> Package rpm-python.i386 0:4.4.2.1-1.fc7 set to be updated
---> Package rpm-libs.i386 0:4.4.2.1-1.fc7 set to be updated
---> Package elfutils.i386 0:0.129-1.fc7 set to be updated
---> Package rpm.i386 0:4.4.2.1-1.fc7 set to be updated
---> Package elfutils-libs.i386 0:0.129-1.fc7 set to be updated
---> Package popt.i386 0:1.10.2.1-1.fc7 set to be updated
---> Package elfutils-libelf.i386 0:0.129-1.fc7 set to be updated
---> Package liboil.i386 0:0.3.12-9.fc7 set to be updated
---> Package liberation-fonts.noarch 0:0.2-1.fc7 set to be updated
---> Package rpm-build.i386 0:4.4.2.1-1.fc7 set to be updated
Dependencies Resolved
=============================================================================
Package Arch Version Repository Size
=============================================================================
Updating:
elfutils i386 0.129-1.fc7 updates 203 k
elfutils-libelf i386 0.129-1.fc7 updates 54 k
elfutils-libs i386 0.129-1.fc7 updates 109 k
liberation-fonts noarch 0.2-1.fc7 updates 638 k
liboil i386 0.3.12-9.fc7 updates 156 k
popt i386 1.10.2.1-1.fc7 updates 70 k
rpm i386 4.4.2.1-1.fc7 updates 1.1 M
rpm-build i386 4.4.2.1-1.fc7 updates 661 k
rpm-libs i386 4.4.2.1-1.fc7 updates 930 k
rpm-python i386 4.4.2.1-1.fc7 updates 56 k
Transaction Summary
=============================================================================
Install 0 Package(s)
Update 10 Package(s)
Remove 0 Package(s)
Total download size: 3.9 M
Is this ok [y/N]: y
Downloading Packages:
warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID 30c9ecf8
Public key for elfutils-0.129-1.fc7.i386.rpm is not installed
Apparently this package is signed with the rawhide key. So one broken package, no updates for anyone until this is fixed.
I think that is the correct behaviour to protect users; having a rpm in a channel signed by the wrong key is really broken and needs to have that channel fixed immediately.
(The repo metadata advertises what keys things in that repo are signed with, and will “do the right thing” and prompt you to install a missing key should it find a package signed by a key that is one of the repo keys, but isn’t imported on your system already)
Comment by Mark Cox — 2007-08-29 @ 10:20
ah! i got that one too. i’m using pup so i un-ticked elfutils and tried again. that works okay (now that they’ve fixed the bug where it ignored all dependencies the second time round!)
i guess there’s a similar “skip this package” option for yum. there’s also the ‘skip-broken’ plugin but that doesn’t appear to do anything.
i totally agree that none of these workarounds should be needed.
Comment by whyohwhyohwhyoh — 2007-08-29 @ 10:30
@Mark: it shouldn’t install the package. But it shouldn’t block all the other updates.
My car doesn’t fall apart when a screw goes missing either. My computer can still work if my DVD drive is broken. As long as it tells me about what didn’t get upgraded it’s fine for me.
Comment by Thomas — 2007-08-29 @ 11:17
Hey Thomas,
it’s not the way to use yum !
The only correct way to use yum is :
yum install apt
apt-get update
apt-get dist-upgrade
You’ll see, the first of those lines is the first sane action to do when dealing with a RPM based distro.
(well, that’s what and my collegues always do)
Comment by Stephane Loeuillet — 2007-08-29 @ 11:39
Of course the unsigned package shouldn’t be installed, but that doesn’t mean it should not upgrade the other packages.
We need to have the –skip-broken behavior integrated upstream and enabled by default. Two problems here.
– Seth Vidal has a somewhat stubborn and despotic approach on the whole issue, for really incomprehensible reasons
– the –skip-broken plugin has its own problems which doesn’t help the point above. It needs to be improved before any upstream push attempt. My experience has been that it doesn’t work as often is it does. The problem is not as simple as one might think, but I’m convinced that common sense and simple heuristics are enough to make a –skip-broken feature that “just works” in most cases. However nobody has stepped up and done the actual work so we’re all to blame here…
Comment by Denis Leroy — 2007-08-29 @ 11:54
if you run “yum update –nogpgpcheck” this will skip the key hcecking bit and the updates will then install as normal.
Comment by Razor — 2007-08-29 @ 12:29
oops – meant to say yum update –nogpgpcheck
Comment by Razor — 2007-08-29 @ 12:35
hmm ok well there are 2 – not 1 before the nogpgpcheck. :-s
Comment by Razor — 2007-08-29 @ 12:36
Try with yum –nogpgcheck update elfutils-libelf.
Comment by RobertoVanto — 2007-08-29 @ 13:54
I agree 100%!
I have the same problem from time to time, I even filled a bug in the bugzilla (https://bugzilla.redhat.com/show_bug.cgi?id=198576), but according to Seth Vidal this is a “wont fix” because it was “addressed many times” and would give the user a “false sense of security”. I even asked him to point out where were those discussions, but I got no answer to that request.
One package that is broken brings down everything, urgent updates will not be applied to an user’s computer because the new features of the gee-wiz he installed from an external repository is not signed properly or it was uploaded with a missing requirement. Now that makes sense.
New way to attack users of fedora, simply put a new gee-wiz software that is not yet packaged, wait until there is a very bad and exploitable security update and upload a broken upgrade to your repo, after that wait watching the logs witch ips are vulnerable and attack. voila a real sense of insecurity. :-P
Comment by Victor Bogado — 2007-08-29 @ 14:42
well atleast the –nogpgcheck option works and gets you apst this problem anyway. Sure wouldbe nive if the problem wasn’t there in the firt place, but a work around is better than nothing.
Comment by Razor — 2007-08-29 @ 15:35
@all people suggesting –nogpgcheck: the main problem is not necessarily that it should be able to install that package. The problem is that there is no way to install all the other packages *without* installing the possibly problematic package.
Comment by Thomas — 2007-08-29 @ 16:03
yum –exclude elfutils\* update
This solves the problem nicely without requiring you to avoid gpgchecks, but don’t forget to backslash the * or it won’t work.
Wasn’t ‘upgrade’ deprecated in favor of ‘update’ ?
Comment by Scott R. Godin — 2007-08-29 @ 16:17
@Thomas: Yum’s –exclude option will allow you to install all the other packages without installing the possibly problematic package.
Assuming the issues could be worked out, I agree that it would ne nice to have the skip-broken functionality in yum, but it should not be the default behavior of the tool. It could be useful to enable such functionality for your nightly cron job to make sure your system is properly patched, for example, but when you are using yum interactively, it’s best for it to either 1) do exactly what you ask it to do, or 2) fail and do nothing.
Comment by Paul Stauffer — 2007-08-29 @ 16:20
“The problem is that there is no way to install all the other packages *without* installing the possibly problematic package.”
Ummm – I think you’re overstating the magnitude of the problem – there is an easy mechanism to do so:
yum –exclude=”elf*” update
Worked for me.
Just a suggestion.
Comment by KushTun — 2007-08-29 @ 16:46
Ahh, the joys of automation. The yum option needs two dashes, not one as suggested by the formatting of the comment above. It’s all explained in “man yum” anyway.
I’ll try again:
yum – – exclude=”elf*” update
The formatting should leave those separate rather than collapsing the two dashes.
Comment by KushTun — 2007-08-29 @ 17:43
“The problem is that there is no way to install all the other packages *without* installing the possibly problematic package.”
You could always exclude a particular package
# yum –exclude= update
Comment by Rahul Sundaram — 2007-08-29 @ 17:43
“–nopgpcheck” is stupid! You don’t have an possibility to deal with this problem once they occur – You need to run the yum once again, and this is really bad (considering that on slower machines with a lot of packages and repos the update process take a lot time!). I had a simillar problem severall times with package conflicts and it took me severall hours each time to resolve this yum mess (and I only had three or four aditional repos!) :-(. I don’t like the idea of using apt on rpm distro (that’s simply idiotic), but what yum does is just terrible :-(
Comment by xxx — 2007-08-29 @ 18:02
I think a lot of people offering solutions are missing the point. Especially Paul in comment 14, saying it should do exactly what I asked it to.
I asked it to upgrade. It should do exactly that. Not fail to upgrade because of one package.
Ideally, yum would do either of the following by default:
a) upgrade everything it can, then give a list of packages it couldn’t upgrade, and why
b) before upgrading, tell me which packages have problems, then ask me [y/n] if I want to skip the broken packages
The tool should do the sensible thing *by default* and not force me to figure out hard-to-remember or easy-to-get-wrong arguments. My point is illustrated by the number of comments on this page that got the option wrong, or the number of dashes, or have disclaimers about backslashes.
Comment by Thomas — 2007-08-29 @ 19:41
As this is a FC7 rpm it looks like there is a problem with the rpm itself. It is probably just a mistake in the spec file. Report it to the fedora list and I’m sure it will get fixed in the next days.
Comment by rasker — 2007-08-29 @ 21:03
@rasker: I don’t want to treat the symptom, I’d like to get the disease fixed. The patient is going to die otherwise.
BTW, like I said, it’s simply signed with the wrong key. It has nothing to do with the spec file. “It will get fixed in the next days” <- who cares ? The problem will pop up again and again under different guises, for no good reason at all.
Comment by Thomas — 2007-08-29 @ 21:51
I agree that it should do the sensible thing. I personally hate when yum fails to contact a mirror and just dies rather than trying another one so I have to sit there and hit the up arrow and enter and presto the next mirror worked. I run into this problem a lot. Doing the sensible thing like skipping the broken stuff is all the more important when you’re looking at 100’s of updates (think new install) and on a slower connection. You’re not going to want to sit around and babysit the update process to find out that what was going to take hours died after 8 min and solved by the program and reporting the errors that couldn’t be solved.
Comment by Biff — 2007-08-29 @ 22:30
I deleted everything (files and directorys) in /var/cache/yum/update and do ‘yum update’. It works as expected. Where is the problem? No software is perfect.
Comment by anonymous — 2007-08-29 @ 22:59
Indeed, this looks quite stupid to delay all updates because one is broken :(
(Most users won’t try to understand the issue and look for an option allowing them to install the other ones)
That could be even worse : an unofficial repository with a broken package could block your security updates !
Comment by Pascal — 2007-08-30 @ 07:05
man oh man
The elf problem seams to be gone, but this is what i’m getting now:
Error: Missing Dependency: rpm = 4.4.2 is needed by package apt
Comment by Fred — 2007-08-30 @ 12:14
I think the skip-broken should be included in yum, but it shouldn’t be enabled as a default (the option –skip-broken should remain needed).
The way I see it is that if I do a yum update and then it fails, I’ll see the error message and figure out what’s the problem (a badly signed package) and how to solve it (exclude the package or wait).
But if yum directly succeeds, only skipping the bad package, all I will see is a “success”. Users don’t pay attention to warning messages but only to a big flashy “FAILURE”. And if yum simply skips the bad package, that’s what the user will do : skip it and never know there was a problem in the first place. How will the bug be reported ? How will I know I can’t trust this package ?
I really think yum’s default behavior is the best, even if it is kind of boring some times…
Comment by bochecha — 2007-08-30 @ 13:08
I see that you are saying that it should just work. However, this comes up again and again in security, the key is there for a reason. If the keys don’t match it should not install. That is the whole point. Yum is working :)
Comment by rasker — 2007-08-30 @ 13:16
@rasker, with all due respect, please take the needle of the broken record and start getting the point. I am completely fine with yum not installing the wrongly signed package, obviously. The point is that it should install all the other, perfectly signed, completely upgradable, packages.
Comment by Thomas — 2007-08-30 @ 13:44
@bochecha and others: I just don’t understand how you consider the current solution to the problem the most obvious one.
You say: “But if yum directly succeeds, only skipping the bad package, all I will see is a “successâ€.”
You think it is THAT hard to make yum say at the END: I skipped this bad package ?
Seriously, it’s just some python code, it can be made to do the right thing.
Comment by Thomas — 2007-08-31 @ 12:00