On Monday, October 13, 2014 6:13:53 PM UTC-5, Charlie Sharpsteen wrote:
>
>
> On Thursday, October 9, 2014 3:10:55 PM UTC-7, John Bollinger wrote:
>>
>>
>>
>> On Thursday, October 9, 2014 9:12:41 AM UTC-5, Felix Frank wrote:
>>>
>>> So in response to Andy's request for a pick, I feel that making packages
>>> non-isomorphic and allow namevar != title would be a fair compromise.
>>>
>>> package { 'mysql-foo': name => 'mysql', provider => 'gem' }
>>>
>>> Yes this might get abused by Forge modules. Nothing we can do about
>>> that, as far as I can tell.
>>>
>>>
>>
>> I'm not so much worried about *ab*use as about well-intentioned and
>> seemingly reasonable use that mixes badly with other well-intentioned and
>> seemingly reasonable use. Hypothetical examples:
>>
>> (1)
>> Module A declares
>> package { 'foo-gem': name => 'foo', ensure => '1.0', provider =>
>> 'gem' }
>> Module B declares
>> package { 'gem-foo': name => 'foo', ensure => '2.0', provider =>
>> 'gem' }
>> Result is that either A or B breaks.
>>
>> (2)
>> Module A declares
>> package { 'web-server': name => 'httpd-server', ensure => '2.0.12' }
>> Module B declares
>> package { 'httpd-server': ensure => '2.4.0' }
>> Again, either A or B breaks.
>>
>> One of Puppet's major features is that it avoids damaging managed systems
>> systems by being conservative about what configuration specifications it is
>> willing to accept. That trait is far more valuable to me than an ability
>> to use specifically the Package type to manage gems etc..
>>
>>
>> John
>>
>
> So, to recap, the issue with making packages non-isomorphic is that the
> title becomes the only method to enforce uniqueness of resources.
>
>
I'd put it a bit differently: the issue with making packages non-isomorphic
is that puppet then *cannot* enforce uniqueness of resources. Resource
titles are arbitrary.
> We may be able to solve the problem of name clashes and retain stronger
> guarantees by switching the Package type to use a composite namevar instead
> of dropping isomorphism.
>
>
I like that better than making Package non-isomorphic. In fact, a
composite namevar is an essential component of my proposed
Secondary_package resource type, for pretty much the same purpose Charlie
describes.
I did not propose doing this for Package itself primarily because it
doesn't completely prevent duplicate Package resources, as Charlie himself
observes (with exactly the example I would have offered myself).
I reiterate that the root problem here is that gems, pips, Perl modules,
etc. are not "packages" in the same sense that packages of the OS's native
type are. Weakening the Package type to better support them at the expense
of continued strong support for the native package type is an unwelcome
trade off. The composite namevar approach offers less of a trade off in
that dimension than does making Package non-isomorphic, but still a
trade-off.
Drawing a clear distinction between primary and secondary packages via
resource types provides an opportunity for more advantages than just
solving the package name issue. A separate type or types for secondary
packages can provide features that don't make sense for primary packages.
For example, they could provide for distinguishing between gems of the same
(gem-)name installed into different Ruby installations.
John
--
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/8c1bf51f-ee5b-45cc-a647-42dc417f0c3c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
