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