Ticket #890 (closed enhancement: fixed)

Opened 12 years ago

Last modified 11 years ago

Packages Plugin does not support alternative package naming conventions

Reported by: Owned by:
Priority: major Milestone: Bcfg2 1.2.1 Release (Bugfix)
Component: bcfg2-server Version: 1.0
Keywords: Cc:


Packages from the IUSCommunity repo ( follow a 'Safe Repo Initiative' ( where packages are named so they do not conflict with a stock distro package (e.g. php is instead called php52 or php53).

As of yum version 3.2.26 this type of package naming convention is supported. See for more info.

The packages plugin, however, does not currently support this. It may pick up older packages because it does not consider a package with a differing naming convention as the correct dependency.


Change History

comment:1 Changed 12 years ago by

Two specific examples I've run into:

1.) rsyslog is installed on centos 5.5 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).

comment:2 Changed 12 years ago by

In testing why the yum3 package this is what I've found so far:

The sources I've defined in 'Packages/config.xml' are being read last to first. The repo (IUS Community) containing the Yum3 package was defined last and therefore parsed first. The Packages plugin treats yum3 as a virtual package (it is named yum3 but provides 'yum') and adds it to the list of dependencies needed for the client.

If, instead, I put the IUS repo at the top of the Packages/config.xml list (and therefore parsed last) the 'yum' dependency has already been resolved by the correct package (yum), and the client is not asked to install yum3.

Soon I'll try and step through the process more closely and see how/why the virtual package logic works and why yum3 is ultimately chosen over yum (or possibly in addition to the yum package).

comment:3 Changed 11 years ago by solj

  • Milestone changed from Bcfg2 1.2.0 Release to Bcfg2 1.2.1 Release (Bugfix)

comment:4 Changed 11 years ago by

  • Owner changed from desai to
  • Status changed from new to assigned

In 1.2.0, Bcfg2 has the option to use native yum libraries for dependency resolution, which I believe may fix this, at least in some cases. If you ask for "rsyslog" explicitly in your configuration, it will not select "rsyslog4," which I think is probably the right thing. But if a requirement is resolved by either the "foo" or the "foo5" package, Bcfg2 will use whichever dependency yum selects. See for information on using the native yum libraries.

I'm having a hard time coming up with a scenario to replicate the issue, so could you test with 1.2.0 using the native yum libraries and let me know your results? Thanks.

comment:5 Changed 11 years ago by solj

  • Status changed from assigned to closed
  • Resolution set to fixed

Resolving as fixed for now as using the native libraries _should_ work. Feel free to reopen if the issue crops up again.

12:32 < solj> aaronlevy: did you ever get a chance to test using the native yum libraries for 12:32 < lopbot> Title: #890 (Packages Plugin does not support alternative package naming conventions) â ... 12:42 < aaronlevy> solj: Sorry, I have not. IIRC defining the IUS repo at the top of config.xml solved our issues at the time (we also don't use the IUS repos anymore). 12:43 < solj> aaronlevy: ah, ok. thanks for the info

WARNING! You need to establish a session before you can create or edit tickets. Otherwise the ticket will get treated as spam.


Add a comment

Modify Ticket

Change Properties
<Author field>
as closed
The resolution will be deleted. Next status will be 'reopened'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.