Packages Plugin does not support alternative package naming conventions

[https://launchpad.net/~aaronlevy]

Packages from the IUSCommunity repo (​http://www.iuscommunity.org) follow a 'Safe Repo Initiative' (​http://saferepo.iuscommunity.org/) 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 ​http://iuscommunity.org/2010/05/06/rhelyum-adds-better-support-for-ius-package-naming-convention/ 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.

[https://launchpad.net/~aaronlevy]

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).

[https://launchpad.net/~aaronlevy]

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).

[https://www.google.com/accounts/o8/id?id=AItOawnSjgovXZr-_V3vGkvMSR0pc5LDykRc1Nc]

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 ​http://docs.bcfg2.org/server/plugins/generators/packages.html#using-native-yum-libraries 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.

[solj]

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 ​https://trac.mcs.anl.gov/projects/bcfg2/ticket/890 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