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:

Feature #5456

package type should accept virtual package for rpm

Added by Michael Scherer over 5 years ago. Updated over 2 years ago.

Status:AcceptedStart date:12/06/2010
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:package
Target version:3.5.0
Affected Puppet version:2.6.4 Branch:
Keywords:

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-897


Description

Rpm ( like many similar package systems ) define a system of virtual package, with the tag Provides. For example, on Mandriva, we have :

$ rpm -q --provides perl-Term-Size-Any-0.1.0-2mdv2010.1
perl(Term::Size::Any) = 0.1.0
perl-Term-Size-Any = 0.1.0-2mdv2010.1

So I can use “urpmi perl(Term::Size::Any)” to install the rpm. On puppet, the type package do not seem to take this fully in account. if I use this :

package { 'perl(Term::Size::Any)': ensure => installed }

The package is installed, but I see a error message :

err: /Stage[main]//Node[valstar]/Package[perl(Term::Size::Any)]/ensure: change from absent to present failed: Could not find package perl(Term::Size::Any)

Here is a patch that fix this. It should allows to use any Provides for all rpm based package managers, but I only checked with urpmi and yum. It should work ok on all of them, since using a Provides instead of the exact rpm name is a very common feature.

0001-allows-rpm-based-package-managers-to-cleanly-support.patch Magnifier (1.1 KB) Michael Scherer, 12/06/2010 12:58 am

History

#2 Updated by James Turnbull over 5 years ago

  • Category set to package
  • Status changed from Unreviewed to Needs Decision

Hi Michael

Our patch submission guidelines are here – http://projects.puppetlabs.com/projects/puppet/wiki/Development_Lifecycle.

The most important step is that you need to sign a CLA.

We can work with on the rest!

Thanks!

#3 Updated by Michael Scherer over 5 years ago

Ok, I have signed the CLA.

#4 Updated by Nigel Kersten over 5 years ago

  • Status changed from Needs Decision to Accepted

#5 Updated by Matthew Mosesohn over 2 years ago

Can anyone comment on the status of this? The fix definitely applies to the case where you try to include package “qemu-kvm”, which is obsoleted by “qemu-kvm-rhev” in RHEL.

#6 Updated by Hunter Haugen over 2 years ago

Can you describe the desired behavior when multiple packages match the provides and there are separate installed/uninstalled states? We need verify that the patch satisfies the behavior and make sure tests are written if possible.

#7 Updated by Michael Scherer over 2 years ago

It would do nothing, and just consider as already installed ( like would yum, urpmi or anything do )

#8 Updated by Matthew Mosesohn over 2 years ago

A key item to note here is yum installs the package correctly, but the verification that the package installation succeeded is what this patch fixes.

#9 Updated by Mark McKinstry over 2 years ago

I’m also affected by this bug.

The main problem is puppet uses yum to install packages and rpm to verify a package is installed. yum understands the ‘provides’ part of an RPM, but the rpm command used by puppet doesn’t.

In terms of what puppet should do when a package is installed which provides something requested, it should do nothing as Michael said since the the requirement for the package is fulfilled. In terms of what it should do if no package is installed, puppet should let yum figure out what to install. Newer versions of yum will install according to this: http://yum.baseurl.org/wiki/CompareProviders .

In terms of a unit test, I’m not sure what you’re looking for but ‘php-common’ provides ‘php-calendar’ on Fedora and CentOS 5 and 6. I can’t imagine php-calendar will be broken off in to a separate package or removed from PHP any time soon so it has some futerproof built in if you use it for a unit test.

#10 Updated by eric sorenson over 2 years ago

  • Target version set to 3.5.0

Pulling this in for 3.5.0 — since there’s code we can probably just do this as part of community pull request triage.

Also available in: Atom PDF