On Mon, 2005-02-28 at 13:27, David Douthitt wrote:
There are already tools to manage packages in each environment; cfengine shouldn't replicate their code.
Yes but their interfaces are different. If I want to know what version
of a package is installed on a Solaris box I'd use something like
pkginfo -x. If I want to know on a stock Red Hat box, I'd use rpm -q. Their output is different, and thus slightly different logic to parse
that output is required.
That's where the wrapper comes in. Use "PkgInstalled" as a function and use "PkgInstalledCmd" as an abstraction. Then you could have this:
linux::
PkgInstalledCmd = ( ReturnsZero("rpm -q %s") )solaris::
PkgInstalledCmd = ( ReturnsZero("pkginfo -x %s") )Cfengine needs to be coded to understand the query command's output (or use a generic wrapper as Tim Nelson suggests). That is all I'm saying here.
I'm suggesting the form of a generic wrapper to be used within cfengine itself in the form of abstracted package commands.
Let me try to illustrate my point with some cfengine code, assuming we used generic names:
control: actionsequence = ( packages ) PkgInstallCmd = ( /usr/bin/yum ) # Note there is no DefaultPkgMgr selected here...
packages: SUNWman pkgmgr=sun action=install lsof pkgmgr=rpm action=install
This to me seems like a good idea... Note that the commands are generic, but the pkgmgr is used to differentiate.
So here, I have an environment where I work with Sun's native packages using Sun's native methods, but when I roll my own packages, I use RPM, and when I query for one of those packages, I ask rpm to find it for me. I am not personally doing this, but I've heard of people who do. I have queried Sun's native package manager for SUNWman, and I have queried the rpm database for lsof. I only have one generic install command, but I have told cfengine to install both of these packages.
Firstly, that makes no sense. In fact, if RPM is properly loaded it MUST be made aware of installed system programs, in order to resolve dependencies correctly.
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 = ...
I'm all for making this more generic if people don't want this flexibility, because I agree that it could pose a scalability issue later.
Who says flexibility needs to be given up?
If we get rid of pkgmgr= for each item, and just make folks set a DefaultPkgMgr up front, we can make the install command generic.
The example you gave _was_ generic....
Of course if we went to a wrapper as proposed, even DefaultPkgMgr becomes useless.
Not necessarily - at least not the way I was thinking of it. DefaultPkgMgr would provide a default for your pkgmgr= item. No pkgmgr= then use DefaultPkgMgr; otherwise use pkgmgr= to override.
-- 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
