[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patch to add install action to packages:
From: |
David Douthitt |
Subject: |
Re: Patch to add install action to packages: |
Date: |
Thu, 03 Mar 2005 05:14:28 -0600 |
User-agent: |
Mozilla Thunderbird 1.0 (Macintosh/20050120) |
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
- Re: Patch to add install action to packages:, David Douthitt, 2005/03/01
- Re: Patch to add install action to packages:, Phil D'Amore, 2005/03/01
- Re: Patch to add install action to packages:,
David Douthitt <=
- Re: Patch to add install action to packages:, rader, 2005/03/03
- Re: Patch to add install action to packages:, Phil D'Amore, 2005/03/03
- Re: Patch to add install action to packages:, David Douthitt, 2005/03/03
- Re: Patch to add install action to packages:, Tim Nelson, 2005/03/03
- Re: Patch to add install action to packages:, rader, 2005/03/03
- Re: Patch to add install action to packages:, Phil D'Amore, 2005/03/04
- Re: Patch to add install action to packages:, Jim Wight, 2005/03/04
- Re: Patch to add install action to packages:, rader, 2005/03/04