Puppet: System Administration Automated

Support

Ticket #265 (closed enhancement: fixed)

Opened 2 years ago

Last modified 1 year ago

Package providers should support architecture pinning

Reported by: lutter Assigned to: lutter
Priority: normal Milestone: elmo
Component: library Version:
Severity: normal Keywords: patch
Cc: Triage Stage: Accepted
Attached Patches: Code Complexity: Medium

Description (Last modified by mpalmer)

The package type should support a new parameter 'arch' that lets the user specify for which architecture(s) to install a given package. The parameter should take an array of strings indicating the architecture. The underlying provider must then only install/update the package for the given arch.

Possible values for the arch:

  • i![3456]86 - 32bit Intel-compatible
  • x86_64 - 64bit AMD
  • ia64 - Itanium
  • ppc - PowerPC
  • ppc64 - 64 bit PowerPC

(Please add other arches, such as various sparc as comments to the ticket)

Attachments

yum_query_provider.patch (1.1 kB) - added by abnormaliti on 05/09/07 09:14:05.
adds a query function the yum provider to support arch's in package names.

Change History

09/14/06 10:49:35 changed by lutter

  • description changed.

09/14/06 10:49:47 changed by lutter

  • description changed.

09/14/06 11:43:09 changed by mpalmer

  • description changed.

amd64 is a common alternative name to x86_64.

I think, though, that this parameter won't be useful for very many systems, as most don't support multiarch in any meaningful fashion. I'd say that just implementing this for the Redhat-related providers for now should be enough, and either ignore or error out if it's specified elsewhere. Does the documentation properly indicate which parameters are valid for which providers?

09/14/06 19:49:56 changed by luke

The documentation usually tries to indicate this, but it's impossible to automatically determine that info at this point. I'd like some way for providers to register this.

03/02/07 06:44:45 changed by abnormaliti

adding the ability to install a specific arch with yum should be a matter of adding a query function to the yum provider? right?

e.g. package { zlib.i386: ensure => installed }

this fails at the rpm provider choking on .i386 when querying the current version.

if you add a "yum list installed zlib.i386" as a query function it would not choke on the above example.

i have looked at the code and i cannot get my head around how to add this myself. i would if i could.

04/05/07 21:51:02 changed by luke

  • specification set to Unnecessary.
  • patch set to None.
  • complexity set to Medium.
  • approval set to Unnecessary.
  • compatibility set to Full.
  • stage set to Accepted.

This should be able to use the Provider Features to accomplish for at least some packaging platforms.

05/09/07 09:14:05 changed by abnormaliti

  • attachment yum_query_provider.patch added.

adds a query function the yum provider to support arch's in package names.

05/09/07 09:26:47 changed by abnormaliti

  • keywords set to patch.
  • patch changed from None to Code.

The attached patch (yum_query_provider.patch) adds a 'query' function to the yum provider, previously it used the rpm query.

This allows packages to be specified in manifests with an architecture appended to the end of the name, as you would with yum on the command line.

e.g. package { "subversion.x86_64": } # this avoids both i386 and x86_64 version being in installed on x86_64 systems package { [ "libgcc.i386", "xorg-x11-fonts-base", "libXtst.i386", "libXrender.i386" ]: } # this installs some i386 packages onto an x86_64 system for 32bit apps, like vmware-server.

note: patch is against SVN/trunk

05/30/07 21:05:05 changed by luke

  • milestone set to elmo.

10/03/07 00:59:15 changed by lutter

  • status changed from new to closed.
  • resolution set to fixed.

Change 8722e4 changes the yum provider to do this using the normal yum syntax: 

  package { "foo": ensure => latest }      # All packages named 'foo' regardless of arch
  package { "foo.i386": ensure => latest } # Only the i386 package

It's a little dirty in that using a name without arch should really be two package resources, but we'll cross that bridge when we get to it.