On Thursday, October 9, 2014 6:36:49 PM UTC-5, Andy Parker wrote:
>
> On Thu, Oct 9, 2014 at 3:10 PM, John Bollinger <[email protected]
> <javascript:>> wrote:
>
> That depends heavily on how you characterize the problem. To me, the
>> clash between packages of different types is primarily a facet of the more
>> fundamental problem that Ruby gems, Python modules, and similar
>> self-contained, distributable nuggets of software simply are not "packages"
>> in the same way that DEBs are on a Debian machine or RPMs are on a
>> RedHat-family machine.
>>
>> The Package type does not need *any* retooling. Instead, a means needs
>> to be provided for people to avoid overloading it with responsibility for
>> managing things it was not designed to handle. I don't even care if all
>> the current Package providers are retained (who knows, maybe some day there
>> will be a RubyOS with gems as the native package type), but where gem (or
>> <insert-name-here>) is *not* the native packaging type, such modules
>> should *not* be managed via Package resources.
>>
>>
> I may have misunderstood your proposal.
>
>
>>
>>
>>> If we open Pandora's box, users will have ample new opportunity to shoot
>>> their own feet. I don't think that there can be a solution that prevents
>>> abuse in the form of conflicting resources, but we do allow a use case
>>> that we know is problematic for several if not many users.
>>>
>>
>>
>> If making packages non-isomorphic were the only viable way to serve that
>> use case then I would find that argument more persuasive. It isn't.
>>
>>
>>
>>>
>>> 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..
>>
>>
> I may not be understanding your proposal. Can you explain how
> SecondaryPackage solves this problem? The way I understand it it just
> pushes the problem down the road a little:
>
> package { 'mysql': ensure => installed }
> secondary_package { 'mysql': ensure => installed, provider => gem }
> secondary_package { 'mysql': ensure => installed, provider => pip }
>
>
Hmm. The primary objective was to solve *precisely* that problem, which it
aimed to accomplish by making the package type a standard parameter and
part of a compound resource name. Probably multiple package types would
then be served by SecondaryPackage providers; if different providers are
needed for different platforms then the supported package types might map
to features. Examples:
package { 'mysql': ensure => 'installed' }
secondary_package { 'mysql': type => 'gem', ensure => 'installed' }
secondary_package { 'mysql': type => 'pip', ensure => 'installed',
provider => 'for_demo_purposes_provider' }
secondary_package { 'mysql': type => 'perl', ensure => 'installed',
provider => 'for_demo_purposes_provider' }
I now recognize that a title collision problem would make this less useful
than I had first thought, but it is *still* better than making Package
non-isomorphic, and Package *still* doesn't need any retooling. The same
applies to managing secondary packages via their own types as Trevor
favors: Package does not need any retooling with that approach, especially
not making it non-isomorphic. I'd be fine with that. I greatly favor
anything else over making Package non-isomorphic.
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/34610cac-3085-417c-8170-82fb9b9fe673%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
