asterisk.pp

# The problem is that an RPM package may have a dependency on the asterisk-11-repo RPM
# package itself. If you install the other package, it will also pull in the RPM package.
# That's a bit icky, to be sure, but it won't actually *break* anything.
#
# The repo package would be installed, which would drop in a .repo file, but only do
# that ONE time. The yumrepo provider would then overwrite it with the actual contents
# as defined in your manifest and then maintain those properties.
#
# This is exactly how it works when you install a package with sample configuration files
# and then manage the real configuration files with Puppet.
#
# A manifest like below will work just fine. The .repo file that exists after Puppet runs
# is exactly what you've defined in the manifest and all dependencies are met.
#
# The other solution, if the name of the repository doesn't match the name of the file, is
# to use a file resource to just manage the .repo file itself.

package { 'asterisk-11-repo':
  ensure => present,
  source => $asterisk_package_url,
}

yumrepo { 'centos-asterisk-11':
  baseurl  => 'http://packages.asterisk.org/centos/$releasever/asterisk-11/$basearch/',
  descr    => 'CentOS-$releasever - Asterisk 11',
  enabled  => '1',
  gpgcheck => '0',
  require  => Package['asterisk-11-repo'],
}

package { 'something-that-requires-asterisk':
  ensure  => present,
  require => Yumrepo['centos-asterisk-11'],
}

Don't you have to insure the repo package (which is actually named asterisknow-version) is installed first to get the behavior you describe? Why would Puppet choose to run yumrepo after the repo package is installed otherwise?

The issue was always that it's a pain in the butt, if not outright absurd and/or dangerous, to maintain the entire repo definition in both places. What you want is to be able to modify the repo:

package { 'asterisknow-version': #asterisk repo
    ensure => present,
    source => $asterisk_package_url,
}

yumrepo { 'centos-asterisk-11':
    require => Package['asterisknow-version'],
    descr => 'The default description for this repo is not as cool as this one that I manually added',
}

In my original case, a repo installed itself in the disabled state; I wanted to simply flip its enabled bit after it installed itself.

That is pretty much what I've been doing (cf. https://github.com/Lullabot/lullapuppet/blob/4b86efe0a9c517abdb78bde883cf7db0e9d83513/asterisk/manifests/init.pp), except the yumrepo name is 'asterisk-11' instead since it matches the repo name in centos-asterisk-11, which is needed. And it works, if the one yumrepo is the only one. (I did understand my use of -> in another bit of mine to be equivalent to require, based on I believe the Learn Puppet tutorial, please do correct me if I'm wrong. I am leaning towards explicitly saying require from here on out though.)

It can break if there are multiple yumrepo resources, though, and the reason appears to me to be that an order like this is selected:

1. yumrepo (any)
2. package that installs new .repo files
3. yumrepo (another, modifying one of the repos added in step 2)

then the step 1 caches the .repo contents internally and that cache is used in step 3. Step 3 doesn't think the new repos exist, so it spits out a new repo definition.

@Zigg, I've updated the gist to follow a variant of the standard Package -> File -> Service pattern. In this case, install a package, update the configuration (.repo file), then use it.

You can also do something like

package { 'asterisk-11-repo':
ensure => present,
source => $asterisk_package_url,
before => Yumrepo<| |>, # resource collector, basically means all yum repositories
}