On Tue, 2005-03-01 at 14:10, David Douthitt wrote:
Phil D'Amore wrote:
On Mon, 2005-02-28 at 13:27, David Douthitt wrote:
That's where the wrapper comes in. Use "PkgInstalled" as a function and use "PkgInstalledCmd" as an abstraction. Then you could have this:
What do you mean use PkgInstalled as a function. Where?
Such as:
gccInst = PkgInstalled( gcc )
linux:: PkgInstalledCmd = ( ReturnsZero("rpm -q %s") )
solaris:: PkgInstalledCmd = ( ReturnsZero("pkginfo -x %s") )
That would get you a yes or no answer on whether or not *any* version of the package was installed.
True.
What packages: can do, as it exists in cfengine today, is check for a package at a specified version. That requires parsing of each commands specific output to determine the version, plus do version comparison based on the logic used by that particular package manager.
Not necessarily. The RPM command, as given, will work with version numbers as well. I would also argue against "parsing output" as the output is not guaranteed to remain the same. For rpm, this command will return the proper value as an exit value:
rpm -q gcc-3.2.3
No matter how much it is abstracted once you sit down to write a cfengine config file, somewhere deep in the bowels of cfengine, something has to understand the output of these various commands, in order to detect and deal with differences in version information.
Not necessarily. All cfengine really has to understand is how to check for an installed package. The output should not even be seen; only an exit value.
The user (or a developer) should be the one who configures cfengine to do what they want. My idea of abstraction would neither be outside cfengine (as was suggested) nor "deep in the bowels" inside cfengine.
I'm merely suggesting the use of a set of configuration variables to be set by the user and utilized by cfengine internally.
However.... putting that aside.... There is no reason that your scriptlet above could not be done using abstraction contained within cfengine. Something like:
control: rpm.PkgInstall = ... rpm.PkgRemove = ... sun.PkgInstall = ... sun.PkgRemove = ...
How is that different from the variables which with you originally took issue? The way I see it, that is the same thing as I originally proposed, sans the .'s of course.
The difference is that the way you suggested it, it was a "name"; here I am suggesting "rpm" and "sun" would be class names arbitrarily chosen by the user, and later utilized in a command to determine which "class" of packaging to use.
This, then, allows the user to extend cfengine to handle packaging types not accounted for by the standard installation - and without having to code or recompile cfengine to do it.
It was generic for a reason: I was trying to illustrate that it won't work. That example used yum to install the packages, yet I had one check for a RPM package and one check for a native Sun package. You can't use yum to install a native Sun package (AFAICT from the website - someone correct me if I'm wrong). So, specifying one install command and querying for the two different types of packages won't work.
So define multiple versions using classes.
DefaultPkgMgr does that already. My point is that if we go to an environment where we only allow one install command, then we can only install one type of package on a given run of the agent. If that is abstracted into a wrapper program/library external to cfengine as has been proposed elsewhere in this thread, then cfengine looses control over what to query to that external facility, and any options inside cfengine to specify it are useless at that point.
I'm not refering to an external library, or to a wrapper program. I'm refering to telling cfengine how to query packages, etc. The current method requires a modification of the code to support unknown package managers, to support changes in output, and to support differences even between two implementations of the same package manager (such as with RPM!).
The evidence of such trouble is evident already in a much simpler area: recognizing operating system versions and releases. HP-UX 11 had this problem, and the numerous various Linux distributions render this almost impossible to keep up with. Does cfengine recognize White Box Linux? TinySofa? Enguarde? Vine? Miracle? Red Flag? And most importantly, can it be made to recognize these variants without recompiling?
Same for package managers - such as FreeBSD packages, HP-UX software depots, and Slackware archives...
Granted, recognizing a Linux variant could be (should be?) easier - a "magic string" file like /usr/bin/file uses.
Perhaps this would be a good place for dynamic code modules? Or is that branching into too much complexity?
-- David Douthitt UNIX System Administrator Linux+, LPIC-1, RHCE HP-UX, Unixware, Linux, FreeBSD, OpenBSD Member: ACM, USENIX/SAGE
_______________________________________________ Help-cfengine mailing list Help-cfengine@gnu.org http://lists.gnu.org/mailman/listinfo/help-cfengine
