Red Hat Bugzilla – Bug 436043
yum-protectbase can't be used with RHN repos., as you can't set options
Last modified: 2010-10-22 19:01:50 EDT
Description of problem:
yum-protectbase plugin needs "protect=yes" to be set in repo configs to protect
a repo. As RHN repos don't have a repo config file, it can't be set.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. install yum-protectbase
2. configure a repo that provides packages that replace packages from the base
3. run yum update
RHN repos aren't protected
RHN repos protected
Attached is a patch to protect RHN repos. In
/etc/yum/pluginconf.d/protectbase.conf, set the following:
enabled = 1
protectrhn = 1
This should make the plugin protect _all_ RHN-configured repos.
Created attachment 296828 [details]
Patch to yum-protectbase to protect RHN repos
I've done several smoketests of this patch and it seems to work.
First, I've simply replaced protectbase.py with the patched version, and enabled
rpmforge (which is known to have a number of conflicting packages w/RHEL). No
non-RHN provided packages were offered for upgrade.
I then subscribed the system to the fastrack channel, and verified that fastrack
packages *were* offered for upgrade.
Jon, the plugin should default to not protecting RHN repos. Can you confirm you
also added "protectrhn = " to protectbase.conf for you tests ?
Just checking my logic is right, old chap ;)
That should have been "protectrhn = 1" of course.
yes, of course :) Sorry bout that.
So while this isn't a horrible fix, per. se. ... this is the wrong solution
IMO. yum-protectbase works with yum repos. it only has problems with the virtual
RHN repos. (and it's _far_ from the only thing that does).
For instance, I've done:
...to try and work around the same problem in RHN repos., but for caching. I've
had other BZs for "exclude" support, then there is "cost" etc. etc.
Aye, I see your point, and agree to a large extent. Looking at the issue, the
options as I see it are:
- work around this in each plugin (a la my patch above)
- modify rhn-plugin to have some way of setting repo config options locally
- move repo option setting into RHN itself
As channel subscription is managed at the RHN end, managing repo options there
too strikes me as the most local place for it (eg. user subscribes to fasttrack
channel in RHN, forgets to go and set protect=yes for it in the right config
file on the machine). It's also the most complex way of doing it, requiring
changes to rhn-plugin, RHN's UI, backend db, etc. Not a short-term solution, by
any stretch of the imagination.
If there's interest in the "do it in rhn-plugin" option, I can have a poke at
the 5.1 version and see what sort of mess I can make :)
Bugzilla seems to bring out the worst in my typing.
Setting 5.3 until such time as 5.4 flag is available.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.
*** Bug 235046 has been marked as a duplicate of this bug. ***