Hi all, On this subject, why don't we do the following: 1. prereqs, keeping the current implementation 2. OPD gets the list of all available packages and populates the database; for that we can point by default to the online repositories 3. install core OPKGs (based on local distro/list of OPKGs) - this has nothing related to any image and cluster deployment, we need these packages. 4. selector fires up based on the default package set and allows users to create the "installed package set" 5. selected opkgs are configured 6. server OPKGs are installed 7. the image is created based on "installed package set" ...etc.
The approach is pretty compatible with everything we did before (only OPD is used in all cases instead of only for third-party OPKGs) and should be pretty simple to implement (does not require a lot of modifications). Regards, 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. > > 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. > > 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. > > 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
