On Mon, 2005-02-28 at 13:27, David Douthitt wrote:
> Phil D'Amore wrote:
> > Don't forget AIX, IRIX, blah blah blah. You or anyone else that
> > needs them are more than welcome to write support for them. Have
> > fun! :)
>
> 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.
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 hope I'm not too late in coming to this discussion, but I would
> suggest that it might be better to have a generic packaging set up, and
> use that instead.
>
> > The thing you need to understand here is that is this matched to the
> > *database* used to store the package metadata. Every database
> > requires different commands to get the job of querying it done.
>
> These different commands should be abstracted. If I want to know if a
> package is installed, then a command PkgInstalled should be sufficient.
>
> > For you other point, if RPM was replaced with something else later
> > on, then it would have a new name, and a different database query
> > method. You can only abstract things so much before you have to deal
> > with the fact that all of these databases are totally different, and
> > you had better know which one you are selecting. Making the names
> > generic is pointless because you lose the ability to select, and we
> > start making ASSumptions of which database to use based on useless
> > data such as the host OS. They need to be distinct for the exact
> > reason you state in your example.
>
> Not so. First of all, the backend database could be anything. RPM
> could change from db3 to mysql, or who knows what else.
>
I think I used the term database on Friday when I really was thinking
about the query interface to the database.
Yes I agree rpm could change its backend database tomorrow (although
it's highly unlikely), but that is an internal detail, and I can almost
guarantee that the query interface to that database (the rpm CLI itself)
would not change.
> Consider apt-get. I can get onto a properly configured Red Hat system
> or a Debian system, use the same command - and not even realize that the
> packaging used is completely different.
>
> It should be this way for cfengine, too.
> As far as "losing the ability to select" - this is not what I had in
> mind. The names should be generic - the configuration should be
> separated and set up by the user. Thus if "PkgInstallCmd" on a Solaris
> system uses RPM, what of it? Configure it that way.... and likewise,
> "PkgEraseCmd" and so forth.
>
> I'm not refering to taking the ability to choose the packaging method
> away from the user - even on the fly - but to taking away the package
> specific naming scheme...
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
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.
What does it do?
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. 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.
Removal is a bit messier because different package managers handle
dependencies differently, but I'm sure this is also something we can
hide inside cfengine, given a bit of work.
Of course if we went to a wrapper as proposed, even DefaultPkgMgr
becomes useless.
Does this illustrate what I'm saying a bit better?
--
Phil D'Amore "Sometimes there is a fine line
Senior System Administrator between criminally abusive
Red Hat, Inc behavior and fun."
Office: 919.754.3700 x44395 -- Ted the Generic Guy
Pager: 877.383.8795 (Dilbert 4/19/2003)
_______________________________________________
Help-cfengine mailing list
Help-cfengine@gnu.org
http://lists.gnu.org/mailman/listinfo/help-cfengine
