The first version would work if packages were implemented with composite
namevars (which they're not). However, it's ugly and shouldn't be necessary
in this case.
The second version should work no matter what but causes confusion when
trying to do any type of resource dependency chaining.
You'd end up with something like:
class foo {
$pkgname = 'bar'
$pkgrealname = 'baz'
package { $pkgname:
name => $pkgrealname,
etc...
}
}
Then, everything else would have to do requires =>
Package[$::foo::pkgname], even though that might just be 'apache' and makes
everything hard to maintain and trace.
Also, you *still* need to be able to detect conflicts between Package
resources of the same provider.
package { 'mysql': provider => 'yum' } should *not* conflict with package {
'mysql': provider => 'gem' }. However, it *should* conflict with package {
'mysql': provider => 'yum', ensure => 'latest' }.
This is actually pretty easy to do in the global validate statement of the
type. However, you'll need to parse the collected yum resources at each
resource declaration to ensure that you don't conflict with anything else
in the stack. I suppose that it could keep track in a hash on the fly, but
that might not be any more efficient depending on how the resource catalog
searches are done (I haven't looked).
Trevor
On Mon, Mar 10, 2014 at 4:53 AM, David Schmitt <da...@dasz.at> wrote:
> On 2014-03-09 21:10, Trevor Vaughan wrote:
>
>> Oh, no, this works perfectly.
>>
>
> Seems like I have some reading to do, or, see below.
>
>
> I just *hate* having to stuff all of
>> that into the name. It makes the hash of options completely pointless.
>>
>
> I want the name/title to be arbitrary and the rest to "just work".
>> Unfortunately, I havent found the special sauce for this yet.
>>
>
> package {
> 'foo:yum':
> name => 'foo',
> provider => 'yum';
>
> 'foo:gem':
> name => 'foo',
> provider => 'gem';
> }
>
> gives me
>
> Error: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Puppet::Parser::AST::Resource failed with error ArgumentError:
> Cannot alias Package[foo:gem] to ["foo"] at /vagrant/vagrant/manifests/
> site.pp:127; resource ["Package", "foo"] already declared at /vagrant/
> vagrant/manifests/site.pp:127 at /vagrant/vagrant/manifests/site.pp:127
> on node puppetmaster.example.com
>
> This tells me that packages do not have composite namevars and that titles
> do not have uniquification abilities.
>
> A composite namevar for packages could include the package name, version,
> arch
> and provider and still work (in the DSL) as usual:
>
> package {
> 'pipedream':
> name => 'foo',
> version => '1.0.0',
> arch => 'noarch'
> provider => 'yum';
> }
>
> would have the title "pipedream", the (composite) namevar value
> "foo:1.0.0:noarch:yum" and the properties and parameters as specified
> above.
> References to this resource could be of the form
>
> * Package['pipedream'], Package['foo:1.0.0:noarch:yum']: specific
> instance
> * Package['foo:1.0.0']: equivalent to Package <| name == 'foo' and
> version == '1.0.0' |>
> * Package['foo']: equivalent to Package <| name == 'foo' |>
>
> I have no idea whether composite namevars work like this, but it is how I
> think
> the problem could be solved.
>
>
>
> Regards, David
>
> Trevor
>>
>> On Sun, Mar 9, 2014 at 6:29 AM, David Schmitt <da...@dasz.at [4]>
>> wrote:
>>
>> On 09.03.2014 03:39, Trevor Vaughan wrote:
>>>
>>> In theory a composite namevar could be used if you just specify
>>>> the
>>>> provider.
>>>>
>>>> For instance, on a Red Hat system:
>>>>
>>>> package { foo: ensure => latest } ==> namevar == foo:yum
>>>>
>>>> And
>>>>
>>>> package { foo: ensure => latest, provider => gem } ==> namevar ==
>>>>
>>>> foo:gem
>>>>
>>>> That said, I never could get composite namevars to work this way.
>>>> I
>>>> always had to have a unique name which ended up in something
>>>> silly like
>>>> package { foo_rpm:} or package { foo_gem:} which, while it should
>>>> work, is absolutely horrible to read.
>>>>
>>>
>>> That was my understanding how composite namevars should have worked
>>> from the beginning. Sadly, this seems "too complex" or "not useful
>>> enough" to be actually implemented. It would even help for
>>> multi-arch and multi-versions installations: "foo:1.0:i386:yum" vs
>>> "foo:2.0:amd64:yum".
>>>
>>> Regards, David
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Puppet Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to puppet-dev+unsubscr...@googlegroups.com [1].
>>>
>>> To view this discussion on the web visit
>>>
>>>
>> https://groups.google.com/d/msgid/puppet-dev/531C426F.1000903%40dasz.at
>>
>>> [2].
>>>
>>> For more options, visit https://groups.google.com/d/optout [3].
>>>
>>
>> --
>> Trevor Vaughan
>> Vice President, Onyx Point, Inc
>> (410) 541-6699
>> tvaug...@onyxpoint.com [5]
>>
>>
>> -- This account not approved for unencrypted proprietary information
>> --
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Puppet Developers" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to puppet-dev+unsubscr...@googlegroups.com [6].
>>
>> To view this discussion on the web visit
>>
>> https://groups.google.com/d/msgid/puppet-dev/CANs%
>> 2BFoUwQXSZ%2BTL%2BxMMMff%3DnGLbpdurM9roQRAETX7EQxGPmQQ%40mail.gmail.com
>> [7].
>> For more options, visit https://groups.google.com/d/optout [8].
>>
>>
>> Links:
>> ------
>> [1] mailto:puppet-dev%2bunsubscr...@googlegroups.com
>> [2] https://groups.google.com/d/msgid/puppet-dev/531C426F.
>> 1000903%40dasz.at
>> [3] https://groups.google.com/d/optout
>> [4] mailto:da...@dasz.at
>> [5] mailto:tvaug...@onyxpoint.com
>> [6] mailto:puppet-dev+unsubscr...@googlegroups.com
>> [7]
>>
>> https://groups.google.com/d/msgid/puppet-dev/CANs%
>> 2BFoUwQXSZ%2BTL%2BxMMMff%3DnGLbpdurM9roQRAETX7EQxGPmQQ%
>> 40mail.gmail.com?utm_medium=email&utm_source=footer
>> [8] https://groups.google.com/d/optout
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-dev/ae3fafce9cb7e3521c2437070c291e2e%40hosting.edv-bus.at.
>
> For more options, visit https://groups.google.com/d/optout.
>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoWadkjhOfWnkdPYVf-4q0mJoRqsFAQWYa%3DfTA1mpd2C_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
