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