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 <a...@puppetlabs.com> wrote:
> On Thu, Oct 9, 2014 at 3:10 PM, John Bollinger <john.bollin...@stjude.org>
> 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 puppet-dev+unsubscr...@googlegroups.com.
>> 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
> a...@puppetlabs.com
> 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 puppet-dev+unsubscr...@googlegroups.com.
> 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
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%2BFoUDdst_tqcxLHuFhQprNc5fNXsRNzAQcmUsW18a1vbc5A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
