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

[Chip Seraphine]

Phil D'Amore wrote:

> Wow, I never realized what a can of worms this would open :).
>
> > 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....
>
>
>
> On the surface this looks like a good thing, but after thinking about 
> I'm not sure how much this buys us.  Consider a package called foo, 
> version 1.0, packaged for a number of different OSes:
>
> RPM-based or debian: 0:1.0-0
> Solaris: a VERSION of 1.0, or something like 1.0,REV=2003010300.
> AIX: 1.0.0.0
>
> Trying to map these to generic land would be an interesting 
> excercise.  You could do 1:0:0:0 which would be nice for AIX to 
> handle.  You could do 0:1.0:0:0 or something which the rpm-based and 
> debian could probably handle.  For solaris, perhaps 
> 1.0:0:0:1003010300, blah blah...  
> [snip]
> Messy.  May as well just use the native scheme for the package manager 
> and explicitly state it as you suggest.  Have multiple entries for 
> differnet package managers if you need to. 

I was assuming that the version strings could be totally unreadable to 
other package formats, and that our interest was in giving a universal 
parsing rule to cfengine.   That being said, multiple entries sounds 
good too :-)

> Perhaps a syntax for specifying where you have a syntax like 
> <namespace>/<version spec> so:
>
> rpm/0:1.0-1
> aix/1.0.0.1
> ...

*now* we're talking.  That is flexible and good.  You also might want to 
allow for definition of a "DefaultPkg" class, out of consideration for 
one-platform shops that don't want to have to have "rpm/" in their 
config file several hundred times.

> [dlopen() and such]
> I had advocated one of 2 approaches, but never persued either:  1) 
> create a stub library that cfengine could load.  If configure detects 
> the presence of rpm on the build host, it will build the stub 
> library.  cfagent could then dlopen() that and do the Right Thing if 
> that fails, as you suggest.  2) Attempt to query directly into the 
> rpmdb using the db3 routines.  

#2 would be slick, but it is basically a hack; and as with any hack, 
that implies a danger of breaking down the road when Things Change.

#1 sounds nicer, since it is so flexible.  Hell, you could have the stub 
lib do  BerkeleyDB queries a la option #2 :-)

I would also suggest that you consider externaling to the rpm executable 
itself whenever possible and just parsing the output.  CFengine does 
this with process lists (kicks off /bin/ps, with a little options hack 
to handle the BSD/SVR4 problem), so you are not harming any sacred 
cattle in doing so.  The performance takes a hit but I'd venture to say 
that is a small price to pay for the transparency you gain.  Besides, 
this isn't the kind of thing you would run every five minutes.

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