RE: Eval'd class to detect installed packages...

[Villalovos, John L]

Is it possible to get a copy of this patch?

Also are there any plans to include this patch in the base distribution
of cfengine?

Personally I think this would be useful.

I realize that I can use something like:

        hasUp2date = ( ReturnsZero(rpm -q --quiet up2date) )

But I kind of like the idea of a built in method :)

Thanks,
John

John Villalovos

My opinions are my own and NEVER the opinions of Intel Corporation.  I
am but a tiny, insignificant, infinitesimal (1/80000) cog in the giant
machine of Intel :)  

> -----Original Message-----
> From: Phil D'Amore [mailto:address@hidden 
> Sent: Monday, December 23, 2002 8:50 AM
> To: address@hidden; address@hidden
> Subject: Eval'd class to detect installed packages...
> 
> 
> Hello...
> 
> I currently have a patch against 2.0.5pre2 that creates a new 
> evaluated 
> class that allows one to determine if a given package is 
> installed on a 
> system.  I only have RPMs to deal with here so the class 
> turned out to be
> 
> RPMHasPackage ( <name> <relop> <[epoch:]version[-release]>)
> 
> Where <relop> is just the usual combinations of <, >, and =.
> 
> My intentions at the moment were to be able to allow cfengine 
> to detect whether packages needed to be installed, and to 
> alter what was done based on the version of an existing package.
> 
> After showing this to Mark, he wondered if it could be made 
> more generic, to allow for the same thing with debian 
> packages.  My immediate thought was to rename the class 
> simply HasPackage, keeping the syntax.  Some issues I am 
> looking for thoughts on:
> 
> 1.  Is anyone interested in this?  Is it worth my time to 
> make this work, or should I just go away and mind my own business?
> 
> Assumung #1 is yes, some other issues...
> 
> 2.  RPM has a 3 part "version", with an epoch, a version, and 
> a release.  Dpkg seems to have a version and a release.  In 
> practice I would imagine it would be fine to just drop the 
> epoch from the version string if it is passed in and we are 
> debian.  Perhaps warn in the debug output.
> 
> 3.  Building in the support.  I see 2 ways to do this.  First 
> and probably easiest is that you get one package system per 
> binary.  That is, you tell configure which package system you 
> want and it makes you a binary with the right code.  This is 
> fine for folks who package cfengine like me, since you can 
> have a debian package for debian boxes and a red hat package 
> for red hat boxes, each with the proper support.  If there 
> are folks doing this sort of thing with all linux boxes on a 
> NFS mount that could be an issue.  The other alternative to 
> accomodate that is to create a binary that dlopen()s the 
> proper libs at runtime based on the running OS.  I've never 
> done that before, however.  The one caveat I can see there is 
> your build host needs to have both rpm and dpkg libs (or at 
> least headers) to make the build work for both.
> 
> 4.  Not a big issue, but I have no idea how to make this work 
> for dpkg.  If anyone knows how to easily do this for dpkg, 
> input from you would be most appreciated :).  A quick search 
> for docs on the API yesterday did not turn up much.
> 
> Sorry for the length.  Anyone with thoughts on what the Right 
> Thing should be?  I currently lurk on bug-cfengine but not 
> help-cfengine, so if writing to the latter, please Cc: me.
> 
> Thanks,
> 
> -- 
> Phil D'Amore                             "Y'know, there was a 
> time when
> Senior System Administrator               corporate 
> responsibility meant
> Red Hat, Inc                              having the decency 
> to jump out of
> Office: 919.754.3700 x44395               a window when you 
> got caught"
> Cell:   919.641.3669                         -- Non-Sequitur, 
> 09/30/2002
> 
> 
> 
> 
> _______________________________________________
> Help-cfengine mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/help-cfengine
>