On Wednesday 17 August 2005 07:09, David N. Lombard wrote: > >>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.
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. > > 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. 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. > > 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. Well, an examination of this lead to the conclusion that some of the package management systems decided to use a common and independent way of caching the package metadata: http://linux.duke.edu/projects/metadata This works for both rpm and deb packages right now. I like it. I played around with yum and createrepo and they almost provide what I was asking for in the past email. They can manage several repositories and it was trivial to build an image or install packages into an image. 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. > > > 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). > > 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. 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. Regards, Erich ------------------------------------------------------- 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
