On Fri, 2009-07-31 at 09:00 +0200, Olav Vitters wrote: > On Thu, Jul 30, 2009 at 04:42:42PM -0400, Owen Taylor wrote: > > What might make sense is to make RPMForge our canonical repo for perl, > > and add to epel.repo: > > > > exclude=perl-* > > > > I don't think it makes sense to do things differently across the > > different servers, so what I'm thinking of is: > > > > Base RHEL repository: protected > > EPEL: protected, exclude=perl-* > > RPMForge: not protected, include=perl-* > > Agree with above. > > Note: I found protectbase not to work for the base RHEL repos. Needed to > modify some file. The rhn-protectbase plugin is on menubar.
I did some experiments with yum-protectbase yesterday, though there ended up not being much point in enabling it in the end, anyways, so I didn't. http://rhn.redhat.com/errata/RHBA-2009-0195.html (from this January) adds support for setting yum options like 'protect = 1' on the RHN repositories. You do this by adding the options to the appropriate section in: /etc/yum/pluginconf.d/rhnplugin.conf (The file doesn't have a x86_64 section by default, so you have to add that for a x86-64 machine. That makes yum-protectbase work itself without needing RHN specifics.) > > (So, perl packages actually in RHEL are still protected and won't be > > upgraded; that can be relaxed if necessary.) > > > > One thing that we have to be careful about with this is that when label > > is added to puppet, then all the custom Perl packages to it will be > > upgraded to the RPMForge versions. AFAIK, none of the other systems have > > any significant Perl services running on them. Maybe we just hold off on > > puppet-managing label until we have bugzilla migrated over. > > RT3 is Perl heavy (window), so was amavis IIRC (menubar) Hmm, so we already have fairly large sets of RPMForge packages on both machines. I went through and looked at the non-perl-* RPMForge packages on both. For Window it is pretty clear that the non-perl RPM-forge packages are just stray upgrades. Window ====== python-paramiko-1.7.4-1.el5.rf 1.7.4 available in EPEL subversion-perl-1.4.3-0.1.el5.rf 1.4.2 is the base RHEL version subversion-1.4.3-0.1.el5.rf 1.4.2 is the base RHEL version python-dateutil-1.2-1.el5.rf 1.2 is in EPEL as well p7zip-4.57-1.el5.rf 4.61 available in EPEL ngrep-1.45-1.el5.rf Not in EPEL. Do we need? Menubar is a more complicated situation, We have the RPMForge versions of clamav and amavis installed, rather than the EPEL versions. Then we have a whole pile of unarchivers that are presumably used by clamav to enhance its operations, many of which aren't available in EPEL. (and gocr - does spamassassin really try to OCR images? Or is it just a stray...) Menubar ======= git-1.5.2.1-1.el5.rf 1.6.0.6 packaged in GNOME repo lzop-1.01-2.el5.rf 1.02 available in EPEL lzo-1.08-4.2.el5.rf 2.02 available in EPEL lzo-devel-1.08-4.2.el5.rf " amavisd-new-2.5.4-1.el5.rf 2.4.5-1.el5 available in EPEL clamav-0.94-1.el5.rf 0.95.1 available in EPEL clamav-db-0.94-1.el5.rf " clamd-0.94-1.el5.rf " cabextract-1.2-1.el5.rf 1.1-5 available in EPEL rrdtool-1.2.23-1.el5.rf 1.2.27-3 available in EPEL nomarch-1.4-1.el5.rf 1.4 available in EPEL ngrep-1.45-1.el5.rf Not in EPEL. Do we need? p0f-2.0.8-1.el5.rf Not in EPEL. Do we need? ripole-0.2.0-1.2.el5.rf freeze-2.5.0-1.2.el5.rf unrar-3.8.2-1.el5.rf zoo-2.10-2.2.el5.rf lha-1.14i-19.2.2.el5.rf arc-5.21o-1.el5.rf unarj-2.63-0.a.2.el5.rf gocr-0.44-1.el5.rf Once we get menubar into the puppet system, I don't see any practical alternative to just listing the 10-15 extra packages we need from RPMForge in our rpmforge.repo includepkgs line. We probably also want to exclude clamav and amavis from epel.repo to prevent them from bouncing back and forth between the package sources. - Owen _______________________________________________ gnome-infrastructure mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-infrastructure
