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

[Phil D'Amore]

Woah.  Sorry about this.  I've been so sidetracked lately that I have 
not had a chance to work through this in a way that pleases everyone 
(never had any takers for helping me get it to work on debian either).  
What cfengine version do you need it for, I will re-generate it for 
you.  Also before I send it out, I want to change the name to HasPackage 
and loose the RPM, in case I ever do get time to make it compatible with 
other formats.

Villalovos, John L wrote:

> 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:damorep@redhat.com] 
> > Sent: Monday, December 23, 2002 8:50 AM
> > To: help-cfengine@gnu.org; bug-cfengine@gnu.org
> > 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
> > Help-cfengine@gnu.org
> > http://mail.gnu.org/mailman/listinfo/help-cfengine
> >
> >    

--
Phil D'Amore                             "Sometimes there is a fine line
Senior System Administrator               between criminally abusive
Red Hat, Inc                              behavior and fun."
Office: 919.754.3700 x44395                 -- Ted the Generic Guy
Cell:   919.641.3669                           (Dilbert 4/19/2003)