Re: Patch to add install action to packages:

[David Douthitt]

Phil D'Amore wrote:
> 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