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): yum-protectbase-1.0.4-3.el5 How reproducible: Always Steps to Reproduce: 1. install yum-protectbase 2. configure a repo that provides packages that replace packages from the base RHN repos 3. run yum update Actual results: RHN repos aren't protected Expected results: RHN repos protected Additional info: Attached is a patch to protect RHN repos. In /etc/yum/pluginconf.d/protectbase.conf, set the following: [main] 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: http://people.redhat.com/jantill/yum/plugins/reset-metadata-expire.py ...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 :)
s/local/logical/ 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 release.
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. http://rhn.redhat.com/errata/RHBA-2009-0195.html
*** Bug 235046 has been marked as a duplicate of this bug. ***