Re: [Puppet Users] Re: Issue: packages with same name, different providers.

Alan Franzoni
Fri, 04 May 2012 13:59:58 -0000

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.

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