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 <john.bo...@stjude.org
> <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 puppet-dev+unsubscr...@googlegroups.com.
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.
