Re: Patch to add install action to packages:

[David Douthitt]

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