[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patch to add install action to packages:
Re: Patch to add install action to packages:
Mon, 28 Feb 2005 12:05:56 +1100 (EST)
On Fri, 25 Feb 2005, Phil D'Amore wrote:
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
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
Am I missing some part of your point here?
Apologies for the following rant, but I hate the package manager
diversity situation :).
First, just so we're all using the same set of terms:
- Package manager (First-level package manager): something like RPM
or DPKG which does base installs, uninstalls, updates, and version
- Repository manager: Does basic operations on repositories, such as
"Get package list", "Get Package Details", "Get package", and the
like (this is generally included as one component of a
second-level package manager, see below).
- Dependency resolver: This basically resovles dependencies between
the packages made available to it through the repo manager, the
command line, and those already installed. This is also generally
part of a second-level package manager.
- Second-level package manager: This basically includes all three of
the above in the one. This is programs like up2date, yum,
apt-get, and the like.
Each of these components seems to be implemented separately by
each group. That's essentially 4 components multiplied by the number of
groups working on it out there. I agree competition is good (Gnome vs.
KDE vs. Enlightenment), but so are standards (X11, HTTP).
Anyway, my idea was that, if there was a library with a standard
API that dealt with even one of these, and backended onto the others, then
if people started using it, at least we'd have a standard.
To now make this relevant to cfengine :), imagine if we had a
(first-level) package API that had commands named after the basic
operations, ie. PackageInstall, PackageRemove, PackageUpgrade,
PackageVersionCompare, and the like, and they had a configuration file
which defined a command to run for each of them, and possibly some control
over getting information from them afterwards. If we had a library like
that, we could just add things to the config file, and they would work.
Now we're presumably not the only ones who could use such an
interface (presumably apt, yum, and the like could use it), so if there
were such a project, we'd presumably have more people working on it than
just the cfengine coders, contributing things for various package formats.
Now the question for Mark: if such a library existed, would
cfengine use it?
(A similar library for repositories would be nice too, but first
things first :) ).
WebAlive Technologies Global
Level 1 Innovation Building, Digital Harbour
1010 LaTrobe Street
Phone: +61 3 9934 0812
Fax: +61 3 9934 0899
"Your Business, Your Web, Your Control"
Re: Patch to add install action to packages:, Mark Burgess, 2005/02/25
- Re: Patch to add install action to packages:, Phil D'Amore, 2005/02/25
- Re: Patch to add install action to packages:, Mark Burgess, 2005/02/26
- Re: Patch to add install action to packages:, Phil D'Amore, 2005/02/26
- Re: Patch to add install action to packages:, Mark Burgess, 2005/02/28
- Re: Patch to add install action to packages:, Phil D'Amore, 2005/02/28