Feature #4074

Package/source should accept puppet:// files

Added by Jean-Baptiste Barth over 1 year ago. Updated over 1 year ago.

Status:Accepted Start date:06/25/2010
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:package
Target version:-
Affected Puppet version:0.25.5 Branch:
Keywords:
Votes: 2

Description

Sometimes you need to use backported packages on debian-like system (we could easily imagine use cases for other platforms). In work/production environments, it’s quite rare to have directly access to the Internet for security reasons. So “package” type should accept a “source” located on the puppet master filebucket, whereas it only accepts local packages for the moment.

Said differently, I’d like to turn this kind of awful recipe :

class apache2-passenger {
  package {“libapache2-mod-passenger”:

ensure => installed,
provider => dpkg,
source => "/tmp/mod-passenger.deb"
require => File[tmp-passenger]

} file {“tmp-passenger”:

name => "/tmp/mod-passenger.deb",
owner => root,
group => root,
source => "puppet:///files/redmine/libapache2-mod-passenger_2.2.11debian-1~bpo50+1_i386.deb"

} }

Into something like this :
class apache2-passenger {
  package {“libapache2-mod-passenger”:

ensure => installed,
provider => dpkg,
source => "puppet:///files/passenger/libapache2-mod-passenger_2.2.11debian-1~bpo50+1_i386.deb"

} }

Let me know your opinion about that. Thanks!

History

Updated by James Turnbull over 1 year ago

  • Status changed from Unreviewed to Accepted

Updated by Andrew Forgue over 1 year ago

It would also be nice to see this in service {} for the manifest attribute.

Updated by Peter Meier over 1 year ago

as rpm or dpkg don’t understand @puppet://@ urls and probably also won’t in the future, enabling that feature wouldn’t be anything else than implementing your workaround into the provider and you can also always abstract that one in define.

Also available in: Atom PDF