I am currently working on a cluster partitioning mechanism which relies on the database, please do not erase tables without consulting me first or i will be in big troubles!
You are currently breaking all the stuff we did this year! On Tue, 2007-10-30 at 19:35 +0100, Erich Focht wrote: > Hi DongInn, > > please don't fix ODA to some sort of fake compatibility mode. The whole > point of doing this exercise was to get rid of a re-invented package > management system for opkgs and use the native pkg management. > > It's now or never! Rather delete code and tables than build compatibility > layers which allow code to behave as before. This will show you what is needed > and what not. And the bugs/failures will point you exactly to the place > where you need to fix things. > > I edited the schema and am about to check it in. > > I don't like that we need something called package_id. I think we can get rid > of the entire Packages table and use opkg names instead in > Node_Packages_Status > as well as in the other remaining packages related tables. > > We could instead populate the Packages table, but that leads into the dead end > with multi-arch/distro setups. > > It's a great chance to clean up, let's do it! > > Regards, > Erich > > On Tuesday 30 October 2007 18:45, DongInn Kim wrote: > > Hi Erich, > > > > Taking out the Package information from ODA is not trivial and it will > > break a lot of database functionalities in OSCAR because many ODA > > subroutines use the Packages table and its primary key, package_id. > > Eventually in order to take out the Packages information from ODA, we need > > to change many parts of the ODA schema. > > I don't think it can be done in a very short time period. > > > > Instead, I would like to keep the ODA stuff as it is for now. Having the > > package information in ODA does not hurt OSCAR at all and it won't affect > > what we want to implement on Select as long as we do not forget to use the > > opkg meta data on Selector. Basically this is what I am doing and will. > > > > More importantly, Selector is heavily using the "Node_Package_Status" table > > containing the primary key (package_id) of the "Packages" table. We can not > > simply make another stuff to replace what the Node_Package_Status table > > does now. I still have a strong feeling that we need to use the > > "Node_Package_Status" whether we keep the Package information (which comes > > from config.xml of all the OSCAR packages) in ODA or not. > > > > So for the short time period, I would like to make ODA work as it does and > > just we use it for "Node_Package_Status" on Selector. > > For the long term, I may want to change the ODA schema to reduce the fields > > of the "Packages" table and remove its weak entity group > > (Packages_requires, Packages_provides, Packages_conflicts, and so on) but I > > still need to keep its strong relation tables (Group_Packages, > > Node_Package_Status, Image_Package_Status) as it is. > > But I still believe that having the full package information in the > > "Packages" table does not hurt OSCAR and it will be just redundant to the > > opkg meta data. > > > > Why don't we just make ODA run as it is and not use it for the "Packages" > > table related queries as much as possible? > > This way, we will not break the OSCAR source codes terribly. Once we are > > not using the ODA "Packages" table any more and we feel that everything is > > ready for using only opkg meta data for the package information instead of > > oda, then let's decide what we want to do with the "Packages" table and > > more stuffs in ODA. > > > > Regards, > > > > - DongInn > > > > > > 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
