Bug 528014

No.

there is no way for yum to know apriori where it  will need packages from. Nor what packages are in what repositories. So it could be that the repo that is unavailable has a package in it which has a security update for the item you're trying to install.

Yum cannot know otherwise. Since repos can impact one another the hard and fast rule is: if a repo that is enabled is down then we abort.

your options are:

1. fix the problem with the repo being inaccessible
2. disable the repo with --disablerepo

Thank you for the explanation.

I see why it makes sense in the usual case - when users install or update software.

My use case is different. I am working on an automatic bug reporting tool (ABRT). It needs to install debuginfo package(s) in order to produce a better backtrace.

backtrace processing starts from core file. abrt retrieves build ids from core file. Then, it checks whether they are installed, by checking whether files with names like

/usr/lib/debug/.build-id/f0/e561d46bad3f089e447085739fdb2009aee6f3.debug

exist. In this exaple, f0e561d46bad3f089e447085739fdb2009aee6f3 is a build id. If they exist, cool, abrt asks gdb to generate backtrace.

But if at least some of them do not exist, abrt tries to install them. Currently, it uses "pk-debuginfo-install PACKAGE", but this is problematic since if PACKAGE was updated, this would install wrong debuginfo.

It makes much more sense to just directly ask rpm/yum to install files we need, since we _know _exact _filename _we _need_!

In this specific use case, yum cannot install "old" package in the sense you explained, because if it installs any package which contains the file we asked for:

/usr/lib/debug/.build-id/f0/e561d46bad3f089e447085739fdb2009aee6f3.debug

it is *surely* the package I need (modulo hash collision, which is virtually impossible). Here, if yum fails, it cannot be useful in any way - abrt will still generate the backtrace, it just will be much less useful for debugging...

Another note: I understand your point that if yum config is broken, then it makes sense to force user to fix it rather than work around it.

However, there is an important scenario where this would not be the best course of action. here is it:

We eventually plan to deploy abrt widely. One use case is "desktop user", where we expect that user usually does not change configuration.

What will happen if user's yum config somehow ended up slightly broken so that normal "yum install ..." works, but "yum install --enablerepo='*-debuginfo' ..." does not, as described in my 1st post?

* user will be able to use yum for install and upgrade
  but
* when something crashes and abrt tries to produce a good backtrace, it will fail to install any debuginfo packages and nearly useless backtraces will be submitted to, say, Fedora bugzilla. User (especially not very geeky one) is not very likely to even notice the problem - he just presses [OK] in the dialogs which ask him to submit a bug...

Do you agree that this would be bad?

Is is acceptable to add an --option to yum which instructs it ti skip "bad" repos rather than abort? Let's call it, say, --skip-bad-repos...

(I am reopening the bug and changing its title)

Then instead of relying on yum as a commandline tool, perhaps abrt should learn how to use yum's internal api. Then it can do whatever it wants.

Problem still exists in:
yum-utils-1.1.24-2.fc12.noarch
yum-3.2.25-1.fc12.noarch

(In reply to comment #1)
> No.
> 
> there is no way for yum to know apriori where it  will need packages from. Nor
> what packages are in what repositories. So it could be that the repo that is
> unavailable has a package in it which has a security update for the item you're
> trying to install.

This reasoning is broken; lets say a user runs yum update to apply some updates (some of them are security updates) .. now an unrelated repo is not accessible, yum aborts and leaves the users system vulnerable.

Here goes your "it is better for security" argument. 
And if the repo is required to pull dependecis it will fail later anyway (as you said it cannot now it beforehand and therefore should not make any assumptions).

> Yum cannot know otherwise. Since repos can impact one another the hard and fast
> rule is: if a repo that is enabled is down then we abort.

It could do better than that.
I agree that it has to inform the user, but aborting is just wrong here.

> your options are:
> 
> 1. fix the problem with the repo being inaccessible

Well users add repos to there system and those might be inaccessible for various reason completely out of the users control. 

> 2. disable the repo with --disablerepo  

Which adds basically nothing but lets the user jump through unnecessary hops. 

(In reply to comment #3)
> Then instead of relying on yum as a commandline tool, perhaps abrt should learn
> how to use yum's internal api. Then it can do whatever it wants.  

AFAIK this has been done for PK (or at least you proposed it there too), but
don't it sound backward to you that every yum user (app not human) works around an issue like that rather than just fix it in yum itself.

And this is why yum bails out. It cannot KNOW what it is going to do is reliable. So it is MUCH better to exit and let an intelligent user fix the problem than let a dumb machine GUESS how to best fix things, potentially hosing it horribly in the meantime.

(In reply to comment #6)
> And this is why yum bails out. It cannot KNOW what it is going to do is
> reliable. So it is MUCH better to exit and let an intelligent user fix the
> problem than let a dumb machine GUESS how to best fix things, potentially
> hosing it horribly in the meantime.

So because on a tiny off chance that it does something someone may not want, everyone writing automated scripts must deal with behavior they do want?  Your argument definitely makes sense in the context of changing the default behavior, but after discussing with a bunch of people having the option of skipping makes more sense than not.  Even the code thought of it as there is a grab_can_fail option that would do it, although its never uses.

That said I believe the default behavior actually is a security hole in of itself.  Think of it this way, let's say we have 5 security updates but one is blocked by a bad or down repo.  Yum currently blocks ALL updates, thus making the system less secure than if it warned the user and applied the other 4.  If one of the other 4 required the blocked update we would error out on that as a dependency check.

Finally, how is this any different then if the package itself was messed up, where yum continues to apply the changes and just errors on that update (and any dependency).  

In conclusion right I would argue that yum is lesss secure and inconsistent with how it deals with errors.  All we're asking for is an option to make it consistent and better, which changes no use case unless we manually edit our code.  As it stands this completely breaks automated processes and unless fixed, we'll probably fork yum or look elsewhere to other package managers.

this is quite an old bug.

you have that option in current yum

skip_if_unavailable

set per-repo.

you can set it from the commandline using

yum --setopt=repoid.skip_if_unavailable=1 restofthecommand

etc, etc

I don't agree with your assessment of the security implications but now I don't have to - you can make your own decisions there.

Seth.  That is awesome.  I did not see it in the bug reports or doc, but will go looking now.  I fear my version of yum (3.2.22) may be too old (we use the CentOs repos) to have this flag, it's not in the help info, but if in the code base this puts it in my hands to track down.

Just reread my report, and must apologize for the tone. Written in the heat of the moment and not my normal more professional way. No offense was meant, I hope none was taken.  Thanks again for the for this info.

This is not currently in rhel5 and I'm not sure if it is slated for a backport.

this bug is against fedora 12 - if you want this option in rhel5 you're going to have to open a different bug about it.

As the RHEL-5 maintainer, I can say that there is _some_ chance that this (and --setopt) could be backported. But it's not trivial.

If you just want something that works for you, you can try the rawhide rebuild repo. And there are the old RHEL-6 rebuild, to RHEL-5, packages (which should be a bit more tested :).

http://repos.fedorapeople.org/repos/james/yum-rawhide/