Erich Focht wrote:
On Wednesday 17 August 2005 07:09, David N. Lombard wrote:
Yes, but a cached dependency tree can exist for the packages you have in a
repository. Or the data for it, in a package-type independent format. See
below.
The dependency info is cached--but it remains abstract until merged with
an actual image or installation when the resolution occurs.
update-rpms doesn't bother me. It bothers me that we cannot use the nice
things in it like caching and dependency resolution for other packaging
systems. I don't want to build dependency resolution into OSCAR if the
infrastructure does what I need.
But, apt, update-rpms, emerge, & etc have their *own* methods to
maintain dependency info and resolve dependencies that are tuned and mature.
What speaks against having a smart package management tool on the clients
(except that we don't have oscar-http yet)? And for installing/deinstalling
packages (also into images) and automatically resolving dependencies. Having
yum or update-rpms on the clients would make the Depman package unnecessary (I
think). Then you can _really_ eliminate the need for dependency info from
OSCAR.
The packman v. depman split was arbitrary. I too would have preferred a
model that sez "do whatever you need to do to install these packages"
(revised-depman/update-rpms) instead of "figure out what I need to do"
(depman/update-rpms) and "install this possibly empty list of packages"
(packman/rpms).
At the end of the day, changing current-depman/packman/update-rpms to
revised-depman/update-rpms is a relatively irrelevant implementation detail.
Here are two things we cannot do right now:
At some stage I would like to see that one master node can manage a RHEL, a
SLES and a Debian subcluster at the same time. From this follows a whish to be
able to deal with multiple package repositories, thus have several dependency
caches.
Disagree. OSCAR should rely on the appropriate tools to do this. On
Debian it's apt; on SuSE, SLES, Mandriva, Red Hat, Red Flag, CSC, et
al., it's some rpm super tool as rpm doesn't handle dependency
resolution beyond the packages identified on the command line.
Even if you disagree, I still think that managing a heterogeneous cluster is A
GOOD THING. I was actually asking for ideas for doing this (easilly).
Sorry, my error in responding. I do agree that OSCAR should be able to
service arbitrary compute node distros and architectures.
I disagreed with the notion that OSCAR needed to take part of the actual
dependency analysis/resolution--that part should be abstracted to apt,
emerge, update-rpms, or yum.
I was thinking of using the update-rpms knowledge for creating a universal
tool. But yes, using high level package management tool below is another
solution. As said above, I'd prefer to see Packman::Yum or Packman::UpdateRPMS
and Packman::Apt instead of Packman::RPM. This makes Depman useless.
As I noted above, the last two sentences are, IMHO, an implementation
detail that is readily changed (at least to the extent of rolling
packman functionality into depman).
--
David N. Lombard
Rossmoor, Orange County, CA
http://www.fourmilab.ch/cgi-bin/uncgi/Earth?imgsize=320&opt=-z&lat=33.8&ns=North&lon=118.08&ew=West&alt=7&img=learth.evif
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Oscar-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
