Puppet users - Jan 2011 - if( defined( Class["software::mongodb"] ) ) throws an error

I''m trying to detect if a class has been defined as is indicated at
http://docs.puppetlabs.com/references/stable/function.html#defined

However, this check always results in the following error:
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not find class software::mongodb at /etc/puppet/modules/
software/manifests/init.pp:36 on node X.XXXX.com

Line 36 is the "if defined" line which doesn''t make any sense
as this
line is supposed to trap that exact condition.  Has anyone else run
into this and / or figured out a way around it?  Thanks.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, Jan 18, 2011 at 02:29, MJ <mj@revmj.com> wrote:
> I''m trying to detect if a class has been defined as is indicated
at
> http://docs.puppetlabs.com/references/stable/function.html#defined
>
> However, this check always results in the following error:
> err: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Could not find class software::mongodb at /etc/puppet/modules/
> software/manifests/init.pp:36 on node X.XXXX.com
>
> Line 36 is the "if defined" line which doesn''t make any
sense as this
> line is supposed to trap that exact condition.  Has anyone else run
> into this and / or figured out a way around it?
It would have been easier to check this if you gave us the fragment of
code that had the problem, and the puppet version you are using.  It
works for me with 2.6.4-363-g27abd84 and 2.6.4 plain, using this
manifest:

    if defined( Class["software::mongodb"] ) {
      notice("defined")
    } else {
      notice("not defined")
    }

Specifically, I see "not defined" announced as expected.  However, be
aware that the ''defined'' function is subtle and strange – it
depends
heavily on the order that your files and classes are parsed in, and
can behave very unpredictably.

Using it is often a sign that something not-quite-right has happened
in your code, so it would be interesting to see how you have written
it; there might be a better way to achieve the same result without the
problems.

Regards,
    Daniel
-- 
⎋ Puppet Labs Developer – http://puppetlabs.com
✉ Daniel Pittman <daniel@rimspace.net>
✆ Contact me via gtalk, email, or phone: +1 (503) 893-2285
♲ Made with 100 percent post-consumer electrons

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

I''m suspect it is one of the "subtle and strange" behavoir. 
I suppose
I should have just posted a link to the code in git hub.  I guess I
was expecting that this would be something that was going to jump out
as something obvious.  My apologies for not doing so.  Here is the
link:

https://github.com/therevmj/puppet-module-software/blob/master/manifests/init.pp

I''m absolutely doing some "not so normal" things in this
module to
obtain the desired effect.  While I liked that idea of loading this
data by including a class, it probably makes more sense to extract all
of the data in my [package_name].pp files into csv files or yaml and
slurp that data in using ''extlookup''.  Initially there was
more logic
in
 [package_name].pp files, but now that they are basically just case
statements setting variables, they don''t really need to be classes
anymore.  Using ''inline_template'' to effectively let me do an
''eval( $software::$name::ensure )'' wasn''t my first
inclination, but at
the time it was what made the most sense.

Thanks for taking the time to respond to my not-so-complete inquiry.
It is much appreciated.

On Jan 18, 11:46 am, Daniel Pittman <dan...@puppetlabs.com>
wrote:
> On Tue, Jan 18, 2011 at 02:29, MJ <m...@revmj.com> wrote:
> > I''m trying to detect if a class has been defined as is
indicated at
> >http://docs.puppetlabs.com/references/stable/function.html#defined
>
> > However, this check always results in the following error:
> > err: Could not retrieve catalog from remote server: Error 400 on
> > SERVER: Could not find class software::mongodb at /etc/puppet/modules/
> > software/manifests/init.pp:36 on node X.XXXX.com
>
> > Line 36 is the "if defined" line which doesn''t make
any sense as this
> > line is supposed to trap that exact condition.  Has anyone else run
> > into this and / or figured out a way around it?
>
> It would have been easier to check this if you gave us the fragment of
> code that had the problem, and the puppet version you are using.  It
> works for me with 2.6.4-363-g27abd84 and 2.6.4 plain, using this
> manifest:
>
>     if defined( Class["software::mongodb"] ) {
>       notice("defined")
>     } else {
>       notice("not defined")
>     }
>
> Specifically, I see "not defined" announced as expected.
 However, be
> aware that the ''defined'' function is subtle and strange –
it depends
> heavily on the order that your files and classes are parsed in, and
> can behave very unpredictably.
>
> Using it is often a sign that something not-quite-right has happened
> in your code, so it would be interesting to see how you have written
> it; there might be a better way to achieve the same result without the
> problems.
>
> Regards,
>     Daniel
> --
> ⎋ Puppet Labs Developer –http://puppetlabs.com
> ✉ Daniel Pittman <dan...@rimspace.net>
> ✆ Contact me via gtalk, email, or phone: +1 (503) 893-2285
> ♲ Made with 100 percent post-consumer electrons
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 01/19/2011 12:39 AM, MJ wrote:
> I''m suspect it is one of the "subtle and strange"
behavoir.  I suppose
> I should have just posted a link to the code in git hub.  I guess I
> was expecting that this would be something that was going to jump out
> as something obvious.  My apologies for not doing so.  Here is the
> link:
> 
>
https://github.com/therevmj/puppet-module-software/blob/master/manifests/init.pp
Interesting construct. Why do you need to go so meta? Usually, instead
of building a framework for packages/services/... that you specify in
some external scheme that you make up, you just write a classes for each
such set in puppet DSL in the first place. Not much more work and much
less of a hassle I''d assume.

But I digress. Concerning your specific problem:

First thing, I guess there''s a misunderstanding on your part as to how
defined() is supposed to check for the presence of class definitions.
That''s actually a documentation bug you''d like to file,
actually.
Observe the following snippet:

class defined_class { }

if defined(defined_class) {
        notify { "Works without Class[] syntax": }
}

if defined(Class["defined_class"]) {
        notify { "Works WITH Class[] syntax": }
}

Yields "Works without Class[] syntax" in 2.6.2.

Now it would have been my guess that variables (parameter values even)
in the argument to defined() might be a problem too, but even this:
class defined_class_a { }

define class_checker() {
	if defined("defined_class_$name") {
		notify { "Class $name is defined": }
	}
}

class_checker { [ "a", "b" ]: }

"correctly" yields "Class a is defined".
So you may get away with fixing your syntax.

You should really file that documentation bug ;-)

Also, if you share more about what you want to achieve with this,
somebody may be able to recommend a more...let''s say "straight
forward"
solution :-)

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Jan 19, 12:58 am, Felix Frank <felix.fr...@alumni.tu-berlin.de>
wrote:
> On 01/19/2011 12:39 AM, MJ wrote:
>
> > I''m suspect it is one of the "subtle and strange"
behavoir.  I suppose
> > I should have just posted a link to the code in git hub.  I guess I
> > was expecting that this would be something that was going to jump out
> > as something obvious.  My apologies for not doing so.  Here is the
> > link:
>
>
>https://github.com/therevmj/puppet-module-software/blob/master/manife...
>
> Interesting construct. Why do you need to go so meta? Usually, instead
> of building a framework for packages/services/... that you specify in
> some external scheme that you make up, you just write a classes for each
> such set in puppet DSL in the first place. Not much more work and much
> less of a hassle I''d assume.
I''ve written up a bit about why I''m writting this module at
https://github.com/therevmj/puppet-module-software/wiki
To ballpark it fairly quickly, having a common namespace for packages
regardless of you platform make writing other modules that are cross
platform compatible easier and more readable, and require less code
duplication.  This comes into play even more when you have to deal
with multiple providers on a single platform.  The amount of code you
end up writing starts ballooning.

Consider that you have written and apache2 module which installs the
correct package and are including it in a manifest with:
    include apache2

What happens when you want to remove this package?  You might just
rework the apache to module to remove ensure that it removes the
packages.  But if you are using it somewhere else, you can''t do this.
You could create a separate class that removes apache, but that will
result in a lot of duplicated code.  Maybe this will work:

    $apache_ensure = "absent"
    include apache2

but you are stuck writing bits of code determine if you should install
or remove that package and you are duplicating that code in each of
your modules.

Ultimately, this seems to me a good way to consilidate the complexity
of dealing with cross platform compatibility issues and enabling
others to focus on the more basic bits of what software needs to be
installed rather than how to do it and what is the package name.  It''s
possible I''m overthinking things, but it has made my other modules
much more straight forward.
>
> But I digress. Concerning your specific problem:
>
> First thing, I guess there''s a misunderstanding on your part as to
how
> defined() is supposed to check for the presence of class definitions.
> That''s actually a documentation bug you''d like to file,
actually.
> Observe the following snippet:
>
> class defined_class { }
>
> if defined(defined_class) {
>         notify { "Works without Class[] syntax": }
>
> }
>
> if defined(Class["defined_class"]) {
>         notify { "Works WITH Class[] syntax": }
>
> }
>
> Yields "Works without Class[] syntax" in 2.6.2.
>
> Now it would have been my guess that variables (parameter values even)
> in the argument to defined() might be a problem too, but even this:
> class defined_class_a { }
>
> define class_checker() {
>         if defined("defined_class_$name") {
>                 notify { "Class $name is defined": }
>         }
>
> }
>
> class_checker { [ "a", "b" ]: }
>
> "correctly" yields "Class a is defined".
> So you may get away with fixing your syntax.
>
> You should really file that documentation bug ;-)
>
I''ve file a bug report on this (and one about the fact that the
documented ''feedback'' tab doesn''t exist).
> Also, if you share more about what you want to achieve with this,
> somebody may be able to recommend a more...let''s say
"straight forward"
> solution :-)
Hopefully my description above conveys the intent of what I am trying
to achieve.  I''m always open to other ideas.  Thanks for your help!
>
> Cheers,
> Felix
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 01/19/2011 11:34 PM, MJ wrote:
>> Interesting construct. Why do you need to go so meta? Usually, instead
>> of building a framework for packages/services/... that you specify in
>> some external scheme that you make up, you just write a classes for
each
>> such set in puppet DSL in the first place. Not much more work and much
>> less of a hassle I''d assume.
> 
> I''ve written up a bit about why I''m writting this module
at
> https://github.com/therevmj/puppet-module-software/wiki
> To ballpark it fairly quickly, having a common namespace for packages
> regardless of you platform make writing other modules that are cross
> platform compatible easier and more readable, and require less code
> duplication.  This comes into play even more when you have to deal
> with multiple providers on a single platform.  The amount of code you
> end up writing starts ballooning.
> 
> Consider that you have written and apache2 module which installs the
> correct package and are including it in a manifest with:
>     include apache2
> 
> What happens when you want to remove this package?  You might just
> rework the apache to module to remove ensure that it removes the
> packages.  But if you are using it somewhere else, you can''t do
this.
> You could create a separate class that removes apache, but that will
> result in a lot of duplicated code.  Maybe this will work:
> 
>     $apache_ensure = "absent"
>     include apache2
> 
> but you are stuck writing bits of code determine if you should install
> or remove that package and you are duplicating that code in each of
> your modules.
> 
> Ultimately, this seems to me a good way to consilidate the complexity
> of dealing with cross platform compatibility issues and enabling
> others to focus on the more basic bits of what software needs to be
> installed rather than how to do it and what is the package name. 
It''s
> possible I''m overthinking things, but it has made my other modules
> much more straight forward.
Hum, I get the feeling there is more than just this removal scenario
that''s bugging you. However, there are rather elegant solutions in the
DSL for that, so I''ll elaborate on this and maybe inspire you to some
other approaches that may help with other problems as well.

First off, don''t rely on dynamic scoping (i.e. variables being
available
in included classes) if it''s at all possible.

What I''d do to make apache2 selectively removable is a subclass:

class apache2 {
  package { "apache2": ... }

  class disable inherits apache2 {
    Package["apache2"] { ensure => absent }
  }
}

Nodes then make sure to not have apache installed by including
apache2::disable.

As for cross-platform, I try to rely on facter to flesh out the minimum
of required discrepancies. E.g., I have a class for the at daemon that
runs on SUSE and Debian systems. Here''s how I work around a problem
with
the SUSE init script:

        package { "at": ensure => installed; }
        if $operatingsystem != "Debian" { #SUSE
                Service { hasstatus => true }
        }
        service { "atd":
                enable => true,
                ensure => running,
                require=> Package["at"],
        }

In more complex scenarios, it may even make sense to specify further
subclasses for specific platforms, but I try and avoid that. The point
is that the module emits a platform-independent interface for installing
and running atd, so platform-specific subclasses actually hurt. The
facter-based constructs can become quite entangled in places, but
they''re meant to be "internal magic" so that''s
usually acceptable.

HTH,
Felix

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

> Hum, I get the feeling there is more than just this removal scenario
> that''s bugging you. However, there are rather elegant solutions in
the
> DSL for that, so I''ll elaborate on this and maybe inspire you to
some
> other approaches that may help with other problems as well.
You are correct, the removal senario is not the only issue.
Ultimately I would like to roll in service and configuration awareness
so that as long as you know what package you want to install, you can
easily make sure any associated service is running and that you have
put config files is the right place.  I''m a long way from that, but
this is just the first step in the journey and I think even by itself
it will prove to be beneficial to the puppet community as a whole.
> First off, don''t rely on dynamic scoping (i.e. variables being
available
> in included classes) if it''s at all possible.
I agree whole heartedly on this.  Technically, I''m not relying on
dynamic scoping.  If the variables are not available in the included
class, things still work as intended.  I''m treating them more as
hints.  I actually spent a fair amount of time trying to figure out a
"config file" format that represented the data I am currently pulling
from the included classes, but I''ve not been able to come up with
anything that represents the complexity and flexability I need without
requiring a minimal programing language and it seems silly to make
someone learn yet another language to do what seems to work quite well
using the puppet DSL.  That''s not to say there isn''t a better
way, I
just haven''t come up with something better.
>
> What I''d do to make apache2 selectively removable is a subclass:
>
> class apache2 {
>   package { "apache2": ... }
>
>   class disable inherits apache2 {
>     Package["apache2"] { ensure => absent }
>   }
>
> }
>
> Nodes then make sure to not have apache installed by including
> apache2::disable.
>
> As for cross-platform, I try to rely on facter to flesh out the minimum
> of required discrepancies. E.g., I have a class for the at daemon that
> runs on SUSE and Debian systems. Here''s how I work around a
problem with
> the SUSE init script:
>
>         package { "at": ensure => installed; }
>         if $operatingsystem != "Debian" { #SUSE
>                 Service { hasstatus => true }
>         }
>         service { "atd":
>                 enable => true,
>                 ensure => running,
>                 require=> Package["at"],
>         }
>
> In more complex scenarios, it may even make sense to specify further
> subclasses for specific platforms, but I try and avoid that. The point
> is that the module emits a platform-independent interface for installing
> and running atd, so platform-specific subclasses actually hurt. The
> facter-based constructs can become quite entangled in places, but
> they''re meant to be "internal magic" so that''s
usually acceptable.
What you point out his is completely true.  I will grant that without
a large number of "package config" class, there is not a lot of value
to my ''software'' resource.  However, as I continue to use it
and
create configs that work on multiple platforms, the number of them
will increase and the amount of work others will have to do to write a
module that is "platform agnostic" will reduce.  I think the git.pp,
git-core.pp, and git-daemon.pp classes and the way they work together
is a really good example of how this becomes beneficial.  When you
start running situations where it takes multiple packages to provide
the same functionality as a single package on another system, things
get hairy.  So far it looks like I''ve been able to move all the
wackiness into the core ''software'' resource with minimal work
int the
"package config" classes.

Now that I have the ''defined'' syntax correct for classes, my
"software" resource will fall back to behaving just like the package
resource.  And because it still does use the package resource on the
back end, it can easily play nicely with existing manifests without
requiring any modifications unless the maintainer decides to convert
everything to the ''software'' resource.

One of the things I''ve found frustrating with puppet is that it
doesn''t come packaged with any modules.  I suspect that''s due
to the
fact that truly generic yet useful manifests are difficult to come
by.  It''s my opinion that if we can reduce the complexity of writing
platform agnostic modules without losing flexibility, we will start to
see modules that are reasonable to include with a base puppet install.

There are a few under the hood enhancements I''m going to add to the
current module and the I will start putting together some decent
documentation and will try to include a good "why would I want to use
this" section.  I don''t know that I''ve yet been able to
properly
explain the benefits I see in this, but hopefully as I put together
the documentation I''ll be able to articulate it more clearly.

Your input (and everybody else''s) is greatly appreciated.
>
> HTH,
> Felix
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is probably the case that you don''t have this class present in
your
autoloader path.

For some reason, Puppet needs the class to be in the autoloader even if
you don''t use it or you run into this exact situation.

I think there''s a bug filed in the Puppet Redmine about it. If
there''s
not there should be ;-).

Try just declaring the class somewhere that the autoloader will pick it
up and just not using it.

Unfortunately, I don''t currently know of a way around this.

Trevor

On 01/18/2011 05:29 AM, MJ wrote:
> I''m trying to detect if a class has been defined as is indicated
at
> http://docs.puppetlabs.com/references/stable/function.html#defined
> 
> However, this check always results in the following error:
> err: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Could not find class software::mongodb at /etc/puppet/modules/
> software/manifests/init.pp:36 on node X.XXXX.com
> 
> Line 36 is the "if defined" line which doesn''t make any
sense as this
> line is supposed to trap that exact condition.  Has anyone else run
> into this and / or figured out a way around it?  Thanks.
> 
- -- 
Trevor Vaughan
 Vice President, Onyx Point, Inc.
 email: tvaughan@onyxpoint.com
 phone: 410-541-ONYX (6699)
 pgp: 0x6C701E94

- -- This account not approved for unencrypted sensitive information --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJNOPe1AAoJECNCGV1OLcypvAIH+wQFZ6wWHyLV4QD3TBVxKCwI
GAMbyDASDTz0XW2Br6rl271LGLzoOJAqRxu5oTUWjTKtaSX7xxkjtUcRbGmBU4X8
0yePO4fnw0yqwYxjNQ/UPDJxDDeNI9Pg2dtyR7XVxuM/SVKltfgKVbM1qJcSthcK
eku9oI9b4uDE0o6T9hC5mcTHAH7+XKhB8d+lmP8Xn4ZG0bTapV+IOZUTcCuOr3jL
NJ9cKXS/lc2Iy2Z3ToZRiNFHUsXNUbZr98LHmk54xJth/x2QbrmmySf2cv42Wxm6
hEi4LzOpjLKIQdOn+/S5hQnxD43zNfXJJA6e3kZc0t0BqDc8Dhl0CvjS31UBmqg=Mv45
-----END PGP SIGNATURE-----

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hey Trevor,

Thanks for the reply.  This thread is way off topic from the original
problem which has been resolved.  Just to clarify for anyone running
into the same problem, the issue was simply the syntax I was using.  I
was checking if a class was defined like this:

   defined( Class["class::subclass"] )

The correct syntax is:

   defined( "class::subclass" )

The documentation is not clear on the proper way to do this.  I''ve
filed a bug report with so this should be getting clarified in the
documentation.  The specific ticket can be viewed here:

https://projects.puppetlabs.com/issues/5944


On Jan 20, 7:04 pm, Trevor Vaughan <tvaug...@onyxpoint.com>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> This is probably the case that you don''t have this class present
in your
> autoloader path.
>
> For some reason, Puppet needs the class to be in the autoloader even if
> you don''t use it or you run into this exact situation.
>
> I think there''s a bug filed in the Puppet Redmine about it. If
there''s
> not there should be ;-).
>
> Try just declaring the class somewhere that the autoloader will pick it
> up and just not using it.
>
> Unfortunately, I don''t currently know of a way around this.
>
> Trevor
>
> On 01/18/2011 05:29 AM, MJ wrote:
>
> > I''m trying to detect if a class has been defined as is
indicated at
> >http://docs.puppetlabs.com/references/stable/function.html#defined
>
> > However, this check always results in the following error:
> > err: Could not retrieve catalog from remote server: Error 400 on
> > SERVER: Could not find class software::mongodb at /etc/puppet/modules/
> > software/manifests/init.pp:36 on node X.XXXX.com
>
> > Line 36 is the "if defined" line which doesn''t make
any sense as this
> > line is supposed to trap that exact condition.  Has anyone else run
> > into this and / or figured out a way around it?  Thanks.
>
> - --
> Trevor Vaughan
>  Vice President, Onyx Point, Inc.
>  email: tvaug...@onyxpoint.com
>  phone: 410-541-ONYX (6699)
>  pgp: 0x6C701E94
>
> - -- This account not approved for unencrypted sensitive information --
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQEcBAEBAgAGBQJNOPe1AAoJECNCGV1OLcypvAIH+wQFZ6wWHyLV4QD3TBVxKCwI
> GAMbyDASDTz0XW2Br6rl271LGLzoOJAqRxu5oTUWjTKtaSX7xxkjtUcRbGmBU4X8
> 0yePO4fnw0yqwYxjNQ/UPDJxDDeNI9Pg2dtyR7XVxuM/SVKltfgKVbM1qJcSthcK
> eku9oI9b4uDE0o6T9hC5mcTHAH7+XKhB8d+lmP8Xn4ZG0bTapV+IOZUTcCuOr3jL
> NJ9cKXS/lc2Iy2Z3ToZRiNFHUsXNUbZr98LHmk54xJth/x2QbrmmySf2cv42Wxm6
> hEi4LzOpjLKIQdOn+/S5hQnxD43zNfXJJA6e3kZc0t0BqDc8Dhl0CvjS31UBmqg> =Mv45
> -----END PGP SIGNATURE-----
>
>  tvaughan.vcf
> < 1KViewDownload
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

> Your input (and everybody else''s) is greatly appreciated.
Hi,

I''ve just given your wiki page a quick read-through.
I can see how this idea can benefit yourself, but I''m somewhat doubtful
that this is going to fly for many other people.

Speaking only for myself, even if I were facing this problem on a
regular basis (I''m not), I''d be hesitant to entrust this
functionality
to a third party solution that may or may not do the right thing (i.e.,
what I expect to happen given a certain requirement) for me.

For example, imagine I compile my own apache packages (with a distinct
package name suffix) because I need some special options. I cannot use a
custom wrapper module like your''s but fall back to doing things by
hand.
There are possibly other exceptional use cases.

But then that''s just me. There may be others who have been waiting for
just such a general purpose module.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.