bcfg2 Packages plugin does not support IUS repo package names

Bug #589473 reported by Aaron Levy
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
DEPRECATED Pantheon
Confirmed
Low
Unassigned

Bug Description

IUS Package names (e.g. php52) are not really supported by the Packages plugin. The plugin may try and use older packages because it doesn't pick up the alternatively named package.

I've filed an issue here: http://trac.mcs.anl.gov/projects/bcfg2/ticket/890. However, I don't think this will be very high priority, and may not be fixed for a while.

One potential option is to just have Packages run blind for CentOS. Because I've already explicitly added all needed packages (no dependencies need to be auto-resolved), we could just remove the centos repos from Packages/config.xml (instead it will just hand down the bundle lists to local yum).

Aaron Levy (aaronlevy)
Changed in pantheon:
importance: Undecided → High
assignee: nobody → Aaron Levy (aaronlevy)
Revision history for this message
Aaron Levy (aaronlevy) wrote :

To update this, it seems like it is working for the most part. The issues I've seen have to do with specific use cases.

For Example:

1.) rsyslog is already installed on images from linode. This conflicts with rsyslog4 (from IUS), as it should. However, because bcfg2 does its own dep resolution, it tries to install the IUS version on top (because it is a newer version) which fails due to conflicts.

2.) Yum is currently version 3.2.22-26. The yum3 package in the IUS repo is 3.2.22-24 (same 'version' older 'release'). However, bcfg2 is still trying to install it as a dependency. The packages conflict (as they should), but bcfg2 tries to install anyway (causing errors).

Both of these issues are resolved with some manual steps. For #1 - uninstall rsyslog using yum shell and install IUS rsyslog4 package. For #2 exclude yum3 in IUS.repo

Leaving open for now as this is less than ideal. I will update the bcfg2 trac ticket with these same specifics.

Changed in pantheon:
status: New → Confirmed
Aaron Levy (aaronlevy)
Changed in pantheon:
importance: High → Low
Revision history for this message
Matt Petrowsky (matt-gotdrupal) wrote :

I'm pretty new to this form of collaboration, but I just installed mercury on CentOS 5.5 today and I used the IUS repos because remi (I read somewere) won't be moving PHP forward after 5.2.

I'm not yet familiar enough with bcfg2 (just started working with it because of this install) but if it's possible, should bcfg2 check repo settings for excludes and the installation of yum priorities plugin? I turned on priorities and I've got excludes on base and updates for *php* and *mysql*

I've got them on other repos I have turned on too like rpmforge and epel. Forcing php and mysql to come from IUS was my goal and I got it worked out (although I'm still getting some verification errors for other stuff). If you want, I can cat my /etc/yum.repos.d/* to see the nice mess I have with trying to get cutting edge on centos. ;) I also updated Packages/config.xml to support IUS and rpmforge.

Revision history for this message
Aaron Levy (aaronlevy) wrote :

The Packages plugin for bcfg2 tries to do all of its the dependency resolution on its own (on the server side), then passes down a full package list to the client. It does not consult with the client configs in this process (e.g. excludes or priorities).

But I definitely asked the same question when I started running in to problems :)

If you take a look at the trunk branch, you can see how we've started setting up the CentOS install. Of particular interest would probably be Bundler/php.xml (for the php 5.2 specific packages) and Packages/config.xml (for the repos we are using).

Except for some issues on specific hosts, at this point we only really need to exclude the yum3 package from IUS (if you see the bcfg2 trac ticket there is a bit more info).

Aaron Levy (aaronlevy)
Changed in pantheon:
assignee: Aaron Levy (aaronlevy) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.