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

[Phil D'Amore]

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

Point is that I can't see any truly package system agnostic way to deal 
with this.  Each system treats the components differently.  Even if we 
reserved, say each space for a different component, you still have 
problems.  Say you had epoch:version:release|revision:whatever.  If I 
wrote 0:1.0.0.0:0:0, this would map to AIX well, but when RPM looks at 
that, it is going to say, "hey, there are more decimal places there.  
Looks newer.  I don't have something that new", when in reality it is 
the same thing.  Worse, if I release a patch, and then I have a RPM with 
0:1.0-1, and an AIX fileset with 1.0.0.1, then you really have an issue 
of mapping the last one to the version or the release.  How can you 
tell?  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.

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

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

I have heard others vioce a real desire to do this, and it fits what I 
describe above, however see my concerns about the runtime issues below.

> 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!")

Yeah, I realized this after writing the e-mail.  I actually spent quite 
a bit of time trying to get the !%^# RPM libs to properly dlopen() (IIRC 
there is no less than 5 interdependant libs that need to load to support 
a simple RPM DB query like I am doing), and was horribly unsuccessful.  
This is mainly because it seemed that the libraries had circular deps 
that could only be resolved by ld, and a mere set of dlopen()s weren't 
getting it done.  I'm willing to concede that I was possibly doing it 
wrong though, since I'm told by those who know better than me that it 
should have worked.  On top of that, since the RPM revision changes from 
release to release (at least, in Red Hat land it does), you have to make 
sure you are trying to dlopen() all possible files for the library revs 
you want to support.  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.  We could create code that could test 
for the presence of the database and try to read it if it is there.  
Here, you would have to be able to tell cfagent where the database 
*should* be, assuming it does not live in /var/lib/rpm.  Failing to find 
the database, an error or a warning could be returned as in 1.  Doing 
this at runtime for many package databases simultaneously could snowball 
rather quickly.  This runtime service switch (which, in effect this 
would create) functionality could well grow into its own package in and 
of itself, at which point, one could apply the same reasoning to not 
bundling it with cfengine as for db3 :).  If you want it, you would 
install it and link cfengine to it. or possibly just try to dlopen() 
that, eliminating any build process modifications.  The benefit here 
would surely be a much more stable interface from cfengine's standpoint.

Later,

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