Re: Perl Packages [was: Re: GNOME Bugzilla Upgrade: Test Upgrade On Friday?]

[Owen Taylor <otaylor redhat com>]

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