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

[Chip Seraphine]

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


It's a fantastic idea.  I would be willing to bet a good portion of the 
people on this list have some sort of hack (module or script) plugged 
into their cfengine setup to accomplish this sort of thing; having it 
organic to cfengine would be a win.

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

I'd try and be even more generic than that, since five gets you twenty 
that somebody will eventually plug this in to Solaris packages, HP SW 
depots, etc.  Just define it has an arbitrary list of version strings, 
and any given package implementation can simply ignore those after a 
certain point.

For example, 1:2:3:4 might map to version 1, epoch 2, release 3 on RPM 
(4 is ignored) and version 1 release 2 on dpkg.  Some undefined 
(future?) package system might care about all four numbers....

You may also wish to have some means of explicitly forcing the package 
type, for unusual client/server situations (or just when somebody does 
something odd like run RPMs on a Solaris box).

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

Nope!  I think you are thinking of runtime linking.  dlopen() doesn't 
really require any compile-time knowledge of the library in question; it 
is all handled at runtime.  Of course, the cost of this is that you do a 
lot of things with function pointers that you would have otherwise been 
able to do with regular symbols, but this really isn't very hard once 
you get used to the syntax (or just #define it away).  

A library would definitely be the 'more proper' way to handle this, 
IMHO.  Attempts to use an unsupported package type could be nicely 
handled at runtime with warnings and such....  ("Error: dlopen can't 
find this lib, you idiot!")

-Chip Seraphine
chip@trdlnk.com
Unix Administrator
Tradelink LLC    Chicago, IL