Issue: packages with same name, different providers.

[Alan Franzoni]

Hello,
I've just run into an issue I'm not able to solve.

I need to have puppet install both the mysql package through yum, AND
the mysql gem.

Those are the pieces of my config as I'm trying to use it:

package { 'mysql-all':
ensure => latest,
name => 'mysql',
provider => yum,
}

package { 'gem_mysql':
ensure => latest,
name => 'mysql',
provider => gem,
}

error from puppet agent:

err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Puppet::Parser::AST::Resource failed with error ArgumentError: Cannot
alias Package[mysql-all] to ["mysql"] at
/etc/puppet/modules/mysql/manifests/init.pp:21; resource ["Package",
"mysql"] already declared at
/etc/puppet/modules/redmine/manifests/dependencies.pp:80 at
/etc/puppet/modules/mysql/manifests/init.pp:21 on node alan.dev.centos6


I must set the name parameter because it's the one that gets used by the
package manager, I've chosen different names for the resources but it
seems like puppet internally forces creating an alias using the package
name.

I've tried manually setting an alias, but nothing changes.

puppetmaster: Debian squeeze, puppet 2.7.14

client: Centos 6 32 bit, puppet 2.7.14.

What should I do?


--
Latest blog post: Deploying WAR on Heroku http://t.co/M4krW2Mu
contact me at public@[mysurname].eu

[jcbollinger]

The $name parameter is both the packaging system's name for the
package and the Puppet name for the Package. If you do not specify
the name parameter then it is taken from the resource title, but
setting different titles, as you have done, does not prevent a name
collision when you specify the same name for different packages.

> I've tried manually setting an alias, but nothing changes.
>
> puppetmaster: Debian squeeze, puppet 2.7.14
>
> client: Centos 6 32 bit, puppet 2.7.14.
>
> What should I do?

The best solution would be to create an RPM of the contents of the
Ruby gem, put it in a local repository, and install it via Yum.

Supposing that the gem is targeted at the system's Ruby (instead of at
some additional, local, Ruby installation), installing via an RPM is
better administratively, as well. It is never good to have multiple
agents managing overlapping spaces.


John

[Alan Franzoni]

On 05/04/2012 03:05 PM, jcbollinger wrote:

> The $name parameter is both the packaging system's name for the
> package and the Puppet name for the Package. If you do not specify
> the name parameter then it is taken from the resource title, but
> setting different titles, as you have done, does not prevent a name
> collision when you specify the same name for different packages.

Yes, I got that. But I'm not really sure whether this is a feature or a
misfeature, or maybe an implementation detail that came out this way.

I mean, resources aren't scoped, so they all get pulled in a global
namespace AFAIK. Beyond the fact that this can create all kind of issues
with modules ( if two modules declare the same title, possibly for
different packages, you've got an unsolvable conflict there), this is an
artificially induced conflict.

if 'name' is the internal name used by the package manager, and there're
multiple different package managers around, I should be able to
differentiate resources. If I need to change the package manager's name
- maybe for every release! - I do need to add a *lot* of overhead to my
configuration management system.

The point of the name check is to prevent an *accidental* clash, but
this is not. This is not even a clash - it's a different package.

> The best solution would be to create an RPM of the contents of the
> Ruby gem, put it in a local repository, and install it via Yum.

This is very time consuming and would require me to create a yum repo,
repack the gem every time I want to update it, instead of just switching
version. Puppet is meant to simplify deployments, not to make them more
complex, right?

> Supposing that the gem is targeted at the system's Ruby (instead of at
> some additional, local, Ruby installation), installing via an RPM is
> better administratively, as well. It is never good to have multiple
> agents managing overlapping spaces.

I don't agree on that - at least, I think you're statement is true only
if you're mixing ruby packages installed via 'gem' and ruby packages
installed via yum/rpm. But that's not my case.

Installed gems are target at system ruby indeed, but while ruby and the
rubygem package itself is installed via system yum, gems are installed
via puppet only. There's no overlap - no ruby gem gets installed via rpm
at any time.