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

[Craig Nelson]

I would be extremely interested in HasPackage functionality. We use RedHat but have recently deployed apt/rpm and it is so incredibly useful. I have a prototype module I was working on where you passed it a list of packages you wanted to check and it set classess if they were installed. Having the functionality built in would be a great boon.

So far as deb versus rpm, I would suggest the compile time flag option. Packages can be difficult enough to build (not that cfengine is) without having to port headers from another distribution over.

~Thanks!

> -----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
>

-------------------------------------------------------------------------------------------
The contents of this email are confidential. If you are not, or believe you may not be, the intended recipient of this email, please let us know by reply and then delete it from your system. You should not copy the message or disclose its contents to anyone. No warranty or other assurance is given by us that this email is free of any virus or any other defect or error.