Hello Erich,
Your email is very interesting and i tried to summarize everything.
To summarize, we needs to manage packages at two different levels:
1/ the OSCAR level, ie OPKG management
2/ the local level, ie managing binary packages on a machine.
(when i say in this email of binary packages i mean RPM or Deb packages)
For that, i think we need to have the following design:
1/ Depman/Packman (OSCAR level)
* providing an high level interface to install OPKG (install_opkg,
remove_opkg, query_opkg, ...etc.).
* find the set of binary packages into the OPKG for the distro (ie find
best
packages, deal with directories in the OPKG for binary packages, ...etc.)
2/ A tool to manage dependencies between binary packages (distro level)
* Depman/Packman identify a set of binary packages for an OPKG but
these
packages can dependent to other packages (can be based on a cache, an a
binary package repository).
* this tool depends to the binary package format and a cache/repository
* this tool can be update-rpm, yum, apt, ...etc.) and is used by
Packman/Depman.
3/ A tool to manage binary packages (distro level)
* install, remove, query on the machine (or into the image) a specific
package.
* this tool can be rpm, dpkg, ...etc. and be used by the dependence
tool
(update-rpm, apt, yum, ...etc.).
I think the key point is to separate mechanisms needed to manage OPKG and
mechanisms needed to manage binary packages on a node.
That means for example for the cache issue, that the tool for the dependencies
management should be able to use a specific cache but according to me, it
does not have to be modified for OSCAR needs. That means that if we need to
do some specific stuff for OSCAR, it should be done by Depman/Packman (or
something else). For the capability to create images based on different
distributions, i think it can be done thanks to Depman and Packman. We can
imagine to extend Depman/Packman (or create a new component) to be able to
create the cache/repository needed for that (downloading packages). But for
that we need to figure out how to deal with the current repository
(/tftpboot/rpm) which is actually manually setup (manual copy of RPMs) and
not usefull if we want to deal with multiple images based on different
distributions.
Finally, the current Depman/Packman implementation is not very usefull for
what we need to do now. I am pretty sure that an implementation based on OCA
(using the OS_Detect framework) should be better.
Sorry, i didn't answer to each points of your email but i wanted to summarize
our needs and see if we can design a first solution.
If this email is not clear or if someone needs more details, i am ready to
start a document the specify in details ours needs and try to find the best
solution.
Thanks,
Le Mardi 16 Août 2005 13:50, vous avez écrit :
> 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
--
Geoffroy Vallée, Ph.D.
SSI-OSCAR (http://ssi-oscar.irisa.fr/)
OSCARonDebian (http://ssi-oscar.irisa.fr/oscarondebian/)
-------------------------------------------------------
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
