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. > > 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. > > 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. Regards, Erich ------------------------------------------------------------------------- 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
