Hello Geoffroy, I'd like to continue this discussion and decouple it from any "feelings" pro/contra package-best, update-rpms and packman/depman. 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.
Your email reminded me that we need to look at two sides: 1. the cluster client nodes : install, remove and update packages. 2. the master node(s) : decide which packages to install in images, find and resolve dependencies. On Saturday 30 July 2005 06:03, Geoffroy R. Vallee wrote: > I am not sure to understand every idea presented in the email but it seems to > me that everybody is not agree on some points according the packages > management at the cluster scale. > I see two kind of issue: > 1/ deal with the direct management of packages on the local node. This is the > goal of the distribution binary format and the associated package manager > (RPM, pkg, apt, ...etc.). Updaterpm is useful on this point, it allows to > find dependencies between packages. Maybe locally there is no need to resolve dependencies, but I might be wrong (example: updating RHEL3 from u3 to u4 on a live system). For management tasks the native package management tool (eg. rpm) should be sufficient, but something automatically resolving dependencies like update-rpms (or yum) is extremely useful. But: that kind of tool needs to create or have access to the cached dependency tree of the repository providing the RPMs. > 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). 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. Because a dependency tree is a dependency tree and doesn't need to know whether it deals with rpms or other types of packages. > I wonder if we don't need to work on depman/packman and not to develop new > independent scripts. Am i wrong? I would like to see of it is possible to > develop a new version of Packman/Depman based on OCA in the framework of > OSCARonDebian (i think the student working on OOD can work on that). Maybe > we can update all together our needs about Depman/Packman and see if it can > ease the management of binary packages in OPKG. > What do think about that? 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. 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. If possible, Packman/Depman should provide the infrastructure to do this with any type of packages. 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. 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
