help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Puzzler: Can cfengine replace make?


From: Mark . Burgess
Subject: Re: Puzzler: Can cfengine replace make?
Date: Tue, 6 Nov 2001 23:43:10 +0100 (MET)

On  6 Nov, Marion Hakanson wrote:
> Steve Traugott wrote:
> 
>> (Cc'ing to both address@hidden and address@hidden).
>> 
>> Many of us commonly use 'make' as a state engine for tracking
>> long-term dependencies over the life of a machine.  For instance,
>> here's a fragment of a real-world makefile, used in a AIX environment,
>> . . .
>> Now, here's the question:  Can anyone see a way to do this once-only
>> type of action cleanly in cfengine?  I've tried several different ways
>> over the years, but I've never been satisfied with the results.  
>> 
>> Steve
> 
> Folks,
> 
> We've also been frustrated here with cfengine's apparently not having a
> way to represent make-like semantics ("update this item only if it's older
> than the source").  A former colleague came up with a trick for dealing
> with this issue in the "editfiles:" section of a cfengine file, basically
> by embedding a timestamp within the file being edited.  Here's an excerpt:
> 

You can do this straightforwardly in cfengine, and it will be even
easier in cfengine 2, but again it boils down to whether you
couldn't do it in a more cfengine like way. It depends on the
problem in each case -- it's like asking for a one to one translation
between German and French. Can't do it for every case.

One has to learn the idioms of each new language. That is the
hardest thing about learning any new software. 

THere are two ways to emulate "do this if file is newer". One is

classes:

 newclass = ( "exec /bin/test file1 -newer -file2" )

# where - newer is whatever it is (I forget)

The other is

copy:

  source dest=dest define=newclass



In both cases, newclass is defined if source is newer
than destination. This can be used to trigger follow up
events. But this is not cfengine thinking. A better way
is to define the way the system is supposed to look (at any time)
and forget about signalling with touched flags etc. The
cfengine way is to view the configuration itself as the
flag which signals "done". That might include updating
certain details if based on updates of source files,
master files etc, or it might be a definition of acceptable
state.

The difference is a subtle one, but I think it's always
doable because the dependencies involved in most tasks
are simple. Make excels at deep hierarchies, but depth is
usually 1 in sysadm.

cheers,

Mark

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Work: +47 22453272            Email:  address@hidden
Fax : +47 22453205            WWW  :  http://www.iu.hio.no/~mark
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~





reply via email to

[Prev in Thread] Current Thread [Next in Thread]