I'm still a big fan of this for clarity and ease of use:
That would conflict for the secondary_package resources. We could try not
> unifying the different providers under a single name:
> package { 'mysql': ensure => installed }
> gem { 'mysql': ensure => installed }
> pip { 'mysql': ensure => installed }
To me, this allows for the correct semantics across the board and is
blatantly/painfully clear.
At some point, when Type inheritance works, the code could be combined and
solidified.
Trevor
On Thu, Oct 9, 2014 at 7:36 PM, Andy Parker <[email protected]> wrote:
> On Thu, Oct 9, 2014 at 3:10 PM, John Bollinger <[email protected]>
> wrote:
>
>> On Thursday, October 9, 2014 9:12:41 AM UTC-5, Felix Frank wrote:
>>>
>>> On 10/08/2014 10:34 PM, Charlie Sharpsteen wrote:
>>> > On Wednesday, October 8, 2014 11:51:32 AM UTC-7, John Bollinger wrote:
>>> >
>>> >
>>> >
>>> > On Wednesday, October 8, 2014 6:55:19 AM UTC-5, Felix Frank wrote:
>>> >
>>> > package { 'mysql-gem': package_name => mysql, provider => gem }
>>> >
>>> > ...which is awful I guess. Anyway, relationship targets will not
>>> be
>>> > jeopardized (that I can see).
>>> >
>>> >
>>> >
>>> > It is more than awful. It either overloads the package title in
>>> > dangerous ways, or else it deeply undermines Puppet's protections
>>> > against duplicate resources. Consider, what is the meaning of this:
>>> >
>>> > package { 'mysql-gem': package_name => 'mysql', provider => 'yum' }
>>> > ?
>>>
>>> Sorry, I should have been more clear. The resource title is supposed to
>>> be arbitrary here. These manage the same resource:
>>>
>>> package { 'mysql-gem': package_name => 'mysql', provider => 'gem' }
>>> package { 'mysql-foo': package_name => 'mysql', provider => 'gem' }
>>> package { 'apache': package_name => 'mysql', provider => 'gem' }
>>>
>>> > Does it duplicate any or all of these resources?
>>> >
>>> > package { 'mysql-yum': package_name => 'mysql', provider => 'yum' }
>>> > package { 'mysql-rpm': package_name => 'mysql', provider => 'rpm' }
>>> > package { 'mysql-gem': package_name => 'mysql' }
>>> > ?
>>>
>>> Only titles clash, so these three could share one catalog. If yum is
>>> your default provider, then the first and third do manage the same
>>> resource.
>>>
>>>
>>
>> In fact, then, if yum is the default provider then *all three* manage
>> the same resource.
>>
>>
>>
>>> > To me, this proposal seams like the most pragmatic way to alleviate
>>> the
>>> > problem without a major retool of how the Package type works. At the
>>> > moment, I'm not convinced that opening up the possibility of
>>> accidental
>>> > misuse outweighs the current issues surrounding the workarounds people
>>> > have to use in order to install a package and a gem that happen to
>>> share
>>> > the same name.
>>>
>>> Thanks for this summary Charlie, it mirrors my feeling quite exactly.
>>>
>>>
>>
>> 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 }
>
> That would conflict for the secondary_package resources. We could try not
> unifying the different providers under a single name:
>
> package { 'mysql': ensure => installed }
> gem { 'mysql': ensure => installed }
> pip { 'mysql': ensure => installed }
>
> That might solve the problem. Are there cases where it won't work? I
> suppose with this scheme we have the ability to make package specific
> types. The pip type could support virtualenv, for example. Would pip and
> gem still be available as providers for the package type? If they are
> available, then we have problems like this:
>
> package { 'mysql': ensure => '2.0.1', provider => gem }
> gem { 'mysql': ensure => '2.4.0' }
>
> If they aren't available, then we've probably broken a lot of manifests.
> Would doing this split result in difficulties making references to
> installed software resources (I'm avoiding using the term packages)? One
> example where it would be difficult is something that installed a package
> via yum on RedHat boxes and gem everywhere else.
>
> There is also the question about what constitutes a native packaging
> system and what doesn't.
>
> I think this proposal might have some promise, but it seems like it opens
> up a lot of arbitrary decisions and unravels into a lot of different
> problems. How deep does the rabbit hole go?
>
> John, could you succinctly outline how you think how we could go about
> doing this and what drawbacks and advantages it might have?
>
>
>>
>> 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/4cd4be7c-c0ce-4700-b0b3-8dafe7bfdf16%40googlegroups.com
>> <https://groups.google.com/d/msgid/puppet-dev/4cd4be7c-c0ce-4700-b0b3-8dafe7bfdf16%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Andrew Parker
> [email protected]
> Freenode: zaphod42
> Twitter: @aparker42
> Software Developer
>
> *Join us at **PuppetConf 2014, **September 20-24 in San Francisco - *
> www.puppetconf.com
>
> --
> 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/CANhgQXs-pcUaDsfkK0ic8GQ82rFaPfQ0x8smVFLZxQEwebDreg%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-dev/CANhgQXs-pcUaDsfkK0ic8GQ82rFaPfQ0x8smVFLZxQEwebDreg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
[email protected]
-- 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUDdst_tqcxLHuFhQprNc5fNXsRNzAQcmUsW18a1vbc5A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
