> Beyond the three listed above, I can think of several: > > * HP-UX software depots > * FreeBSD packages > * Slackware packages >
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! :) > And this doesn't account for alternative installation programs, although > that may not be relevant - RPMInstall command could be set to "apt-get > install" for instance. > > However, I find the names "RPMInstallCommand" et al to be just ghastly. > What if RPM is phased out and replaced with the new name > FooBarPackageMgr? What if someone installs RPM on a SUN machine? What > if someone installs RPM onto Debian and uses it? More importantly, how > are you EVER going to be able to get ALL package managers represented? > > The commands ought to be package manager neutral, should they not? 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. Just like you said, you can install RPM on a Solaris box. So, you might want to be able to query both the RPM and the Solaris-native databases, maybe even at the same time? At the same time, if you are doing something like that, then it is possible you may want to install some OS package from Sun in their native format, which would have to be stored in the native solaris package database, and at the same time be maintaining your own local custom packages in RPM, or whatever. It's all about the database. If I'm looking for a package in a particular database, and I decide to install it, then I'd better use the install command that is aware of that database. I'm perfectly aware that people use apt-get and other programs to update their RPM packages, and that is why you have the ability to select the program to use based on the database in which you were looking for the package in the first place. 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. Am I missing some part of your point here? -- 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
