The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:

Bug #1398

Common package name in two different providers

Added by Lawrence Ludwig almost 8 years ago. Updated over 2 years ago.

Status:AcceptedStart date:07/07/2008
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:package
Target version:-
Affected Puppet version:3.3.1 Branch:
Keywords:package alias

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This ticket is now tracked at: https://tickets.puppetlabs.com/browse/PUP-1073


Description

I have a common package name, that’s in two different package managers (one with yum the other with gem)

    package { "remove-mysql":
            name     => "mysql",
            provider => "yum",
            ensure   => absent,
    }

    package { "gem-mysql":
            name    => "mysql",
            ensure   => "2.7",
            provider => gem,
    }

I get this error.

Jul 3 08:43:34 puppetd[11872]: Could not retrieve catalog: Puppet::Parser::AST::Resource failed with error ArgumentError: Cannot alias Package[gem-mysql] to mysql; resource Package[mysql] already exists at /etc/puppet/modules/ruby-mysql/manifests/init.pp:11 on node


Related issues

Related to Puppet - Feature #1621: Composite resource identifier Closed 09/29/2008
Related to Puppet - Bug #8596: Title and name must be unique within a given resource. Closed 07/23/2011
Duplicated by Puppet - Bug #16177: Packages with the same name but different provider cannot... Duplicate 08/30/2012
Duplicated by Puppet - Bug #18926: Package names not qualified by provider Duplicate
Duplicated by Puppet - Feature #20922: Duplicate package names from different providers Duplicate
Duplicated by Puppet - Bug #11887: Package with different providers should not violate dupli... Rejected 01/11/2012
Duplicated by Puppet - Feature #2692: Allow duplicate resource names for a resource with differ... Closed 10/02/2009
Duplicated by Puppet - Bug #973: Packages with the same name in different providers cannot... Closed

History

#1 Updated by James Turnbull almost 8 years ago

  • Category set to package
  • Status changed from Unreviewed to Rejected
  • Keywords set to package alias

You can’t have two resources with the same name. You need to alias it to something else.

#2 Updated by Lawrence Ludwig almost 8 years ago

jamtur01 wrote:

You can’t have two resources with the same name. You need to alias it to something else.

You can’t alias it, see thread

http://groups.google.com/group/puppet-users/browse_thread/thread/9dd0bbc0317b7a99/3ac57871ab7d3422?lnk=gst&q=package#3ac57871ab7d3422

#3 Updated by James Turnbull almost 8 years ago

  • Status changed from Rejected to Accepted
  • Assignee set to Luke Kanies
  • Target version set to 4

#4 Updated by Luke Kanies almost 6 years ago

  • Assignee deleted (Luke Kanies)

#5 Updated by James Turnbull over 4 years ago

  • Target version deleted (4)

#6 Updated by Kristian Kostecky almost 4 years ago

This is still an issue in puppet 2.7.14.

#7 Updated by Ken Coar over 3 years ago

Still an issue in Puppet 2.7.18.

#8 Updated by andrew grim about 3 years ago

Is this something that will ever be fixed? If not, what is the reasoning behind it? Telling people to rename their packages isn’t a very useful answer when public repositories are being used.

#9 Updated by Pedro Côrte-Real almost 3 years ago

Just hit this exact issue and was impressed it’s a 5 year old bug. It’s been filed as a feature but it really is a bug. There should be a straightforward way to express in puppet that “package [pkg] should be absent in [providerA] and installed in [providerB]”. Renaming packages isn’t an option given that in a lot of cases these are in fact the same package, where debian/redhat has packaged in through their tools and ruby/python through theirs. Even if they’re not the same packages expecting that all the Package providers have non-clashing namespaces is just asking for trouble.

It would probably make sense for Package to have a $pkgname property that defaults to $name to get around this.

#10 Updated by Trevor Vaughan almost 3 years ago

+1 to Pedro’s suggestion.

A composite namevar with pkgname and provider is the way to go.

#11 Updated by Ken Coar almost 3 years ago

  • Affected Puppet version changed from 0.24.4 to 2.7.21

+1 to Pedro’s suggestion.

#12 Updated by Spencer Krum over 2 years ago

Another +1 for Pedro’s suggestion.

#13 Updated by Adrien Thebo over 2 years ago

My understanding of this issue is that there is no tidy solution to this issue. While it may make sense to have multiple packages with the same name but different providers, it breaks down when applied to other types. For instance, you can’t have two groups with the same name but different providers (or if you do, it’ll get ugly). Alternately, what happens when you have a manifest like this?

package { 'htop':
  ensure => present,
  provider => apt,
}

package { 'htop':
  ensure => absent,
  provider => dpkg,
}

In this case, is it acceptable to let those two resources constantly break each other?

In addition, how do you refer to resources by reference with the same name but different providers?

package { 'redis':
  ensure => present,
  provider => yum,
}
# => Package['redis:yum']      It's reasonable for packages to have a `:` in the title, depending on the provider
# => Package[['redis', 'yum']] This would require overhauling the API and would be probably VERY backwards incompatible

I’ve personally run into this problem and it is a real problem, but the reason this has been open for 5 years is because it’s not a 5 line patch. To fix this we need to hammer out a solution that addresses the issue of specifying the name and provider in resource references and determining what types and providers can support duplicates, and what types and providers can’t.

#14 Updated by Pedro Côrte-Real over 2 years ago

Adrien, your example doesn’t work of course because you can’t have two resources with the same name, but you don’t need that for this to work. An example would be:

package { 'somepackage-in-apt':
  ensure => present,
  pkgname => 'somepackage',
  provider => apt,  
}

package { 'somepackage-in-gem':
  ensure => absent,
  pkgname => 'somepackage',
  provider => gem,
}

And this would properly ensure the package is installed through apt and not rubygems. Your apt/dpkg example is a corner case since in the outside (puppet) world apt is layered on top of dpkg. It’s up to the user that “if it hurts when you do that, stop doing that”.

Not having looked at the code I do think this shouldn’t be such a complex fix as the current difficulty isn’t enforced by the puppet type system, just by the fact that the current package implementation uses $name for setting the package instead of $my_other_random_name_variable. Creating $pkgname ||= $name like I suggested would fix this while being backwards compatible.

#15 Updated by Xavier Nicollet over 2 years ago

  • Tracker changed from Feature to Bug
  • Affected Puppet version changed from 2.7.21 to 3.3.1

Just want to install memcached server, and memcached gem (the client) on the same host:

package { 'memcached':
    ensure => installed,
    provider => gem,
}

package { 'memcached':
    ensure => installed,
    provider => apt,
}

Can’t use puppet for that on this host. So, should I go back to some hand made scripts ? Is there any workaround ?

(for me, it is clearly a bug, not a feature request). Still present in puppet 3.3.1.

#16 Updated by Jason Antman over 2 years ago

Redmine Issue #1398 has been migrated to JIRA:

https://tickets.puppetlabs.com/browse/PUP-1073

Also available in: Atom PDF