On Tuesday 30 October 2007, Erich Focht wrote: > On Tuesday 30 October 2007 19:22, Geoffroy Vallee wrote: > > On Tue, 2007-10-30 at 17:12 +0100, Erich Focht wrote: > > > Hi, > > > > > > since the oscar call was interrupted, we should continue on the mailing > > > list. > > > > > > DongInn described in the call how the installation steps go in the old > > > OSCAR: 1. prereqs get installed (these are not opkgs, normally) > > > 2. ODA is fed with config.xml data > > > 3. core opkgs installed > > > 4. selector is used to edit the default package set > > > 5. ... selected opkgs are configured > > > 6. server opkgs are installed on the master > > > > > > In the new setup we don't have the information from config.xml > > > available and the ODA packages info is empty. We are directly querying > > > the repositories so we can use selector without ODA, more or less. But > > > it is unclear what is the best way to initiate and describe steps 1. > > > and 3. in the new setup. > > > > > > For the start I would propose to leave the prereqs installation as it > > > is and expect the prereq packages to be in the repositories. > > > > A solution is to ship prereqs via binary packages and therefore include > > scripts into binary packages and express dependencies via the binary > > package management system; the same way we are currently using OPKGC. > > But this is an optimization, we can keep the current prereqs > > implementation. > > That works, but doesn't solve some things doable by prereqs easilly: > removing some rpms and executing some (arbitrary) scripts. It can be done > over the long term, but not in the next week.
Yes but on this other side you are deeply modifying the OSCAR architecture which mid-term will be pretty bad for other projects. Binary packages can also give you conflicts and dependencies. Based on that i think it should be pretty simple to implement what i propose. > > > > Step 2 is skipped. > > > > > > The step 3 can actually be done using the same querying functions we > > > use in the selector, i.e. the functions from OpkgDB.pm: build a hash > > > with all packages, find out which packages are "core" (multiplexed into > > > the group information) and install their opkg-*-server rpms. > > > > > > When we're done with the selector it should create the default package > > > set records. > > > > Be careful there because you loose the capability to say "OPKG bla is > > not supported on the Linux distribution RHEL5 x86_64". The default > > package set current aims at giving the set of OPKGs that are shipped > > with OSCAR and supported for a each distro. If you create the default > > package set based on Selector, you loose this capability. I think the > > package set from Selector is not the default package set but the package > > set defined by the user, which may be different. Also note that the code > > for a clean package set management is not complete. > > I don't like the idea of having a superset of okgs on the master. Actually. > We aim for a quick way to get trunk running again, after 4 months(?). It's > time for action. Sorry but it works pretty well on Debian (i do not say it is perfect). RPM developers have been inactive, this is another problem. Do not generalize your situation. And why you do not like this idea. Without a clear explanation, sorry your point of view cannot be accepted. BTW, i has ready to explain my latest developments and try to federate efforts. Do you try to communicate with me? If do not think so... > > > > I think this is easilly doable and follows the philosphy of removing > > > packaging info from the database. All we need in the database is the > > > default package set and the package status. Other things can be read on > > > the fly. > > > > I agree it may be a way to release something quickly but remember that > > mid-term we want to be able to deal with cluster partitioning and so on > > (OPM/NEST). If you remove data from ODA all these features cannot be > > implemented and that will be a big problem for my current projects > > (cluster partitioning, virtualization and so on). As i said before i > > strongly think we need to have all needed information about OPKGs into > > the database; i cannot imagine to have to query all images and all the > > nodes every time i will want to get information; that will kill some of > > the features we want to support (e.g. scalability). > > What you need is neither the Packages table, nor the > Packages_requires/provides, you need the Node_Pakages_Status, and that is > the one which must stay, of course. Wrong. Package allows me to tack simply the list of OPKGs available for each distro/architecture. Currently Yume and Rapt are slow like hell for the first tests i did it was not acceptable with several clusters, images and partitions. So what you said does not make sense; by experience i know that we cannot rely only on yume and rapt to query the list of OPKGs. So i think we need to use the database for that (which implies the Packages table). But at the same time, the package table does not need to have the list of all the binary package, just data about the OPKG. Typically the binary package management system does not give global information, only local information. Information in ODA are supposed to give you this global view. It was always been done that way in OSCAR why do you want to change everything? I know that you want to almost delete the database since you joined the project but other developers reply on it. BTW, Node_package_status without the Package table does not make any sense!!! At least because a key used in Node_Package_Status comes from the Package table. So yes, your modifications break everything! > > Regards, > Erich -- Geoff ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
