On Monday, June 13, 2016 at 5:21:42 AM UTC-5, Justin Rowles wrote:
>
> At risk of bumping a now truly ancient thread (which I found because I
> have a 3rd party module and one of my own which both want to control a
> specific package), I don't see why puppet should complain when two
>
It most likely has to do with creating the graph of dependencies, if we
have one Package['a'] with two branches of deps it can't guarantee that it
is acyclic.
--
Lowe Schmidt | +46 723 867 157
On 13 June 2016 at 12:21, Justin Rowles wrote:
> At risk of bumping a now
At risk of bumping a now truly ancient thread (which I found because I have
a 3rd party module and one of my own which both want to control a specific
package), I don't see why puppet should complain when two identical (or at
least non-contradictory) invocations of the same resource are found.
Whoo, the triumphant return of a thread from over two years ago ^^
Still, this has come up on the development list again, too, recently.
There has not yet been significat progress and we are still stuck with
the workarounds from the olden days. You can try with the
ensure_resource() function (in
I am surprised there is no viable solution to this seemingly basic
problem... I maintain a comprehensive set of Puppet modules for our
internal software and while it hasn't been an issue yet, having two modules
attempt to install the same package (ie. openssh-clients on RHEL) is
certainly not out
For this kind of stuff i created a package module that only ships packages
potentially shared (python lib, curl, etc...).
I virtually déclare un thé module ans realie un the main modules
Le 27 mars 2014 15:03, och ach och...@gmail.com a écrit :
same problem here. just find that razor module has
On Friday, March 28, 2014 10:14:56 AM UTC-5, Mike Frisch wrote:
I am surprised there is no viable solution to this seemingly basic
problem... I maintain a comprehensive set of Puppet modules for our
internal software and while it hasn't been an issue yet, having two modules
attempt to
I do the same currently. I have a module that installs/updates an
in-house-developed scientific application with many os package (yum) and python
module (pip) dependencies. I recently wrote a second module for another
scientific application with overlapping dependencies and saw duplicate
Oh right.
Yes, of course, it *can* (and should!) be solved cleanly if you are in
control of all involved modules. It gets hairy were third party modules
enter the fray.
Cheers,
Felix
On 03/28/2014 04:32 PM, Peter Bukowinski wrote:
I do the same currently. I have a module that installs/updates
On Friday, March 28, 2014 9:18:20 AM UTC-5, Felix.Frank wrote:
Whoo, the triumphant return of a thread from over two years ago ^^
Still, this has come up on the development list again, too, recently.
There has not yet been significat progress and we are still stuck with
the workarounds
same problem here. just find that razor module has static def of package
curl.
what is the best practice?
for now i have deleted the definition from module and included my virtual
packages definitions but would love to solve it not dirty fix it
On Saturday, 21 January 2012 15:02:27 UTC+1, bel
I find it confusing that Puppet defines modules as reusable code yet,
when it comes to packages, you have to have prior knowledge of what
other package resources are defined.
Thank you for all the proposed solutions but does anyone know if
Puppet has a best practice they recommend in this case?
I add my 2 cents.
The alternatives proposed in the replies are ok for me, just would like to
express an alternative approach that I''ve used in some situations.
It's due to different factors:
- Many packages to manage (but not necessarily)
- Option to include a module in an existing module set,
On Jan 20, 4:34 am, Alessandro Franceschi a...@lab42.it wrote:
I add my 2 cents.
The alternatives proposed in the replies are ok for me, just would like to
express an alternative approach that I''ve used in some situations.
It's due to different factors:
- Many packages to manage (but not
On Jan 18, 5:52 am, Felix Frank felix.fr...@alumni.tu-berlin.de
wrote:
Hi,
On 01/17/2012 04:11 PM, jcbollinger wrote:
The first is simpler only if you get lucky, and you don't intend to
modify your manifests ever again.
basically correct, but you can even play it safe: You must make
On Wed, Jan 18, 2012 at 3:52 AM, Felix Frank
felix.fr...@alumni.tu-berlin.de wrote:
Is there a good reason that this function is even retained in recent
versions of puppet? I have yet to encounter an instance where it can be
used cleanly.
I'll start another thread about this, but I'd quite
Hi,
On 01/17/2012 04:11 PM, jcbollinger wrote:
The first is simpler only if you get lucky, and you don't intend to
modify your manifests ever again.
basically correct, but you can even play it safe: You must make sure
each and every invocation of the resource in question is protected by
such
On Jan 17, 3:11 am, Steve Shipway s.ship...@auckland.ac.nz wrote:
You can make the package resource definition conditional.
class foo {
if ! defined( Package[gcc] ) {
package { gcc: ensure=installed; }
}}
class bar {
if ! defined( Package[gcc] ) {
package { gcc:
Usually creating a separate class is best, but for odd single packages
I'll add them to a single class as virtual resources.
oneoffpackages {
@package {'mysql-client'}
@package { 'perl-Getopt-Long-Descriptive': }
}
Then when I want to use that package I'll realize it.
nrpe::delllperc {
19 matches
Mail list logo