Re: Patch to add install action to packages:

[Phil D'Amore]

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)