[Top][All Lists]

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

Eval'd class to detect installed packages...

From: Phil D'Amore
Subject: Eval'd class to detect installed packages...
Date: Mon, 23 Dec 2002 11:50:00 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003


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 

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.


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

reply via email to

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