Johnny Hughes wrote on Thu, 04 May 2006 13:57:10 -0500:

I think it should be:

(for kbs) protect=1

and

(for dag) protect=0

ahm, yes, of course, I typed that from memory, just a typo.

Also ... did you remember to add plugins=1 to your /etc/yum.conf file.

It's all okay, protectbase *does* work, (proven by the fact that the rpmforge clam package - 0.88.2 - doesn't try to upgrade the kbs-extras package - 0.88.1 - ) but not in this case! It seems the replace/obsoletes or whatever is in the rpmforge package overrides the protect. And even if it didn't work it wouldn't explain the difference between check-update and update. That should always be the same. If yum shows something different when doing check-update than what it is then actually going to do I can't rely on check-update (and protect in this case). Anyone has clam from kbs-extras installed and not yet upgraded?

Kai

Johnny Hughes wrote on Thu, 04 May 2006 17:06:00 -0500:

It is a replacement and not an upgrade that is causing the issue ... kbs (it seems) doesn't have clamav-db.

No. It seems that clamav-db is the whole signature db, providing it as an upgrade package is somewhat mute I guess.

So it seems that clamav-db gets to be installed, since it is not protected. Installing it causes something else to get removed (which should be protected) ... but that happens after the initial calculations, and it seems protectbase is not working on that set.

I am sure this is a protectbase plugin issue and not a yum issue. Though it should be consistent between check-update adn update.

I have submitted for a bugzilla account at the yum duke site, but am still waiting for the mail. I hope I'll get one soon. Then I submit it.

Kai

Johnny Hughes wrote on Sun, 07 May 2006 10:49:42 -0500:

Assuming what I found to be true ... this is not a bug with yum or protectbase ... or even I problem with the repos individually ... but a problem if dag and kbs are used together.

It is a problem whenever a package obsoletes another package and that or it's name is in other repos as well.

---

If you want to use Dags repo for clamav:

in the kbs-CentOS-Extras repo add this line:

exclude=clamav*

Sure, I can do this, but I have to do this without protectbase, anyway.

As a side note, this kind of problem happens quite frequently when more than one repo is used.

But the whole point of protectbase is that it *protects*, isn't it? I mean in my eyes "protect" means "protect" against replacement by another repo by whatever means. I don't care if it updates, obsoletes or whatever. Why should "obsoletes" be handled different?

Kai

Johnny Hughes wrote on Sun, 07 May 2006 16:13:47 -0500:

I read man yum and came to the conclusion that it is not a problem between update and check-update. These *can* be different. check-update doesn't do dependency processing. It also mentions that the difference between update and upgrade is --obsoletes, but I don't see a difference in output at the moment.

Because ... that is a second set of calculations

In the first set of calculations, all the packages where the names match up are done .. hmmm, a new package named clamav-db is needed (and there is nothing protected to prevent that). In a second set of calculations ... clamav-db obsoletes something else.

So, what protectbase does is calculate a merged list of the repos and if any package is on that list any updates from unprotected repos for it will be ignored. However, then clamav-update gets processed and checked for dependencies and that reveals the obsoleting package clamav-db (but how? see below). That's not on the list, so it gets installed. That's then at least a shortcoming of the way that protectbase works. Nevertheless, it's not really clear to me how the clamav-db package comes into play. When dependencies are checked it should just check what's in the spec file of the clamav-update package. But additionally it seems to query all repos for packages updating/obsoleting this update?

If you try to install it doesn't do it

I didn't try that. I thought I can rely on what update tells me before the update.

.. NOW ... if the names were

the same (with or without the obsoletes) this would not happen.

I agree. But this means that any repo can even overwrite the base repo just because it obsoletes some package that is named the same as in the base repo. This shouldn't be able to happen if I take "protectbase" literally.

Kai

Daniel de Kok wrote on Mon, 08 May 2006 08:38:20 +0200:

But in the context of the priorities plugin this should mean that if a package with a lower priority obsoletes a package with a higher priority, it should be excluded. I'll try to add an option to the priorities plugin to do this.

It is desirable, I don't know if it's easily possible, though. I hope you can get it incorporated.

Kai

Johnny Hughes wrote on Sun, 07 May 2006 10:37:10 -0500:

clamav-db (dag) IS a different name ... but the same thing as clamav- data (kbs).

Yes, from the size and the name this is possible.

It also seems that clamd (dag) is the same thing as clamav-server (kbs).

Quite possible.

So .. it seems that what is required to make both of these repos to be enabled at the same time is for dag to add these obsoletes:

In clamav-db: obsoletes clamav-data In clamd: obsoletes clamav-server

and for kbs to add these:

In clamav-data: obsoletes clamav-db In clamav-server: obsoletes clamd

I think the solution above fits in general if you do *not* use protectbase. It's then maybe a question of who wins the race? So, whichever of the two is first processed may obsolete the other and the second obsoletes may not work and still produce an undesired result? An obsoleted rpm gets completely replaced by the new rpm, even if the content or name is different. The whole problem *is* created by that replacing in the first place.

clamav-db i386 0.88.2-1.el4.rf rpmforge 4.0 M replacing clamav-update.i386 0.88-1.el4.kb

So, clamav-db already contains a "obsoletes clamav-update" and "clamav-update" also exists in the kbs repo. And dag seems to have had a "clamav-update" in the past and moved that (which probably just contains freshclam and crontab for it) to the db in one package. That is what creates the whole problem, at least in my eyes.

The question then is: why would I want a package from protect=0 not update a package from protect=1, but replace it? Does it make sense to let this package get replaced, although the repo is protected? I don't think this makes sense. So, the flaw seems to be in yum and/or protectbase.

Additionally, what makes me think there's something wrong in yum/protectbase is the difference between check-update and update. It seems to me the different update behavior occurs because update actually downloads the rpm and may get more information then. In the light of that information the following action may be quite reasonable. However, that means that it decided to download clamav-db *first* - which it should not have done at all. So, there *must* be happening something different here between update and check-update as well - and that is certainly wrong, no matter if the other problem is a protectbase or a repo problem. Or not?

Kai