Erich Focht wrote:
Hello Geoffroy,
I'd like to continue this discussion and decouple it from any "feelings"
pro/contra package-best, update-rpms and packman/depman.
I'm truly sorry if I hurt your "feelings." Having said that, emotions
are irrelevant.
The target should be
to get the package management clearly defined and under control, with
non-replicated easy to maintain code which is mostly independent of the
package type. This seems to fit well into oscar-devel, so I changed the
subject and switch to oscar-devel.
This is the framework we have; it's only been realized for RPMs, so may
well need tweaking when we add another package management system.
2/ we need a mechanism to deal with packages at the cluster scale. That means
find the best packages, construct a dependence tree between packages to
install at the cluster level, ...etc. This is the goal of depman/packman.
Unfortunately, the current version of Depman/Packman does not provide the
complete set of functionalities we need, and is not very useful (according to
me).
Dependency resolution can only be done correctly against a target with
installed packages, i.e., an image that a node will be synced to, or
each node, independently.
I believe Depman uses the update-rpms dependency tree implicitely. IMO this
should be only a workaround until we code cached dependency management which
is independent of the type of package.
Disagree. There is no reason for OSCAR to know anything about package
management or dependency resolution. OSCAR only needs to know "what"
packages to install, not how or why. I really don't care if update-rpms
is used or not; if update-rpms bothers you, replace it, say with yum.
Just don't build dependency resolution into OSCAR.
Because a dependency tree is a
dependency tree and doesn't need to know whether it deals with rpms or other
types of packages.
This confuses the near trivial effort to resolve dependencies with the
massive effort to collect the dependency information, which is strictly
dependent on the package system. Any examination of update-rpms, yum,
apt, portage, or any other such system will reveal this.
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.
Another whish: we should be able to upgrate images and installed nodes
in yum-like way, this means automagically, without having to deal with
dependencies.
Dependency resolution is exactly what yum provides...
If possible, Packman/Depman should provide the infrastructure to
do this with any type of packages.
Disagree. Depman/Packman should rely on tools developed for the purpose
of resolving dependencies, like update-rpms, yum, apt, emerge, &etc.
Update-rpms could be a solution, but then
one needs to recode the whole stuff for Debian packages, too and maintain it
in at least two separate complex package managers.
Disagree. One does not need "to recode the whole stuff for Debian
packages." One does need to understand that Debian already has apt, and
we just need a small mechanical bit of code in Depman and Packman to
call it--that's why depman/packman exist, to abstract that work.
--
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
