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.
For more options, visit https://groups.google.com/d/optout.
