Hi, here is an attempt to document the changes made for getting a 5.1 alike branch to work. Besides the opkgc bugs (thanks to DongInn for helping to fix them).
1) Database schema change Eliminated package_id as reference from several tables to packages. Replaced by package (name), a string, but as good as an integer index. This has the advantage of making sense even when the package record is changed and the id changes, e.g. when the package version changes. Replaced group_id by group_name in some places. Added "distro" field to the package record, this is for multi-distro support. The Database.pm interfaces changed minimally, the content of the functions was simplified. Database.pm shrinked by 200 lines of code but is still to big. 2) OSCAR::OpkgDB This is in trunk. OpkgDB are database-like functions querying the remote YUM / APT repositories and/or the local RPM/DEB database instead of ODA. The functions return info about opkg-* metapackages (api, server, client) and return similar values like the database queries (arrays of hashes with the field keys as index). They are designed to replace ODA queries (which address cached package info) by direct queries of the package manager or repository databases. A performance problem might exist but is normally uncritical. 3) OSCAR::PackagePath Added functionality to manage the repositories for a distro. They are stored in the files /tftpboot/oscar/<compat_distro>-<version>-<arch>.url . This was anyway the place where the repsitories could be configured. yume received an interface for controlling these repositories from the command line: --repoadd|--repodel|--repolist . But it is only able to modify the repositories of the locally detected distro. For other distros: use PackagePath. By the way: list_distro_pools can be used to enumerate the configured distros, i.e. those for which distro (not oscar) repositories are configured. 4) OSCAR::Opkg Some extensions for opkg handling and installation. Main difference to trunk: replaced opkg_install_server() by a more general opkg_install(). 5) scripts/populate_oda_packages_table Used for compatibility reasons. Populates the new Packages table with info retrieved from repositories about the opkg-* metapackages. Can accept as argument a string describing the distro, in which case it will query the corresponding distro and feed info on those packages to ODA. 6) wizard_prep logic change - prereqs install - install all available opkg-API metapackages (for the master node) on the master node. This brings the opkg API scripts to the master node, including the setup scripts. Before: API scripts came with OSCAR. Now they come from the repository during the startup of the wizard. If new repositories were added, restart the wizard. - run package setup scripts (like before) - create a hash array of the locally installed opkgs (needed for install steps). Is equivalent to a database query, but until now we actually would not need the database to be up. - prepare_oda (starts mysql, creates the tables?) - populate_default_package_set (not sure this script works, actually) - populate the default package set from the share/package_sets/Default/*.xml (this needs XML::Simple, but actually what we manage (a list of opkgs) isn't really worth a xml file and all the infrastructure around it. - create default package configs by interpreting their configurator.html files. - set_node_nics - install core opkg-*-server packages - mark packages installed in Node_Package_Status table - run post_server_install scripts for the core packages - export local pools to clients through http. 7) Fixed Selector to manage package sets Re-enabled package sets management. Use OpkgDB queries instead of ODA for populating tables. Sets are created in the Group_Packages table and package group files are written in $OSCAR_HOME/tmp/*.pgroup All set management functions work: duplicate, rename, create all/core, delete. Fixes from DongInn for package manipulation are included. 8) Added functionality to SystemInstaller for selecting package groups when building images. These are passed from the outside, if nothing is passed, things work like before. The package groups functionality is problematic because the master gets the _selected_ package set from Selector, i.e. the one which is active when closing the Selector. If this set is not the union of the other sets, the master node might miss packages. This needs to be fixed, a superset of all packages can be created easilly on the fly. For now: make sure you select a big enough set on the master node. Oh, there is a limitation: we cannot handle requirements and conflicts of opkgs right now. Also the servicelists and switcher info is missing. The reason is: opkgc cannot put this into rpms right now. We need to find a way to transport this information. An example: we multiplex class and group information into the Group: field of RPMs. Need something similar for DEBs, and for the additional info. There might be more changes, but I don't remember. I also updated some packages (e.g. systemimager-4.0.0) but these are merged to trunk. 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
