Hi, What is/are the key(s) for the new Package table scheme you propose? I do not have access the SVN today, sorry.
Regards, Quoting Erich Focht <[EMAIL PROTECTED]>: > Hi, > > here's the current state of the schema in my branch. It is prepared to be fed > with info retrieved by OpkgDB (maybe not complete, but mostly). > > Removed tables: > Packages_requires > Packages_provides > Packages_conflicts > This info is never needed. It is automatically resolved by the native package > manager. The only place where we might need it is in the selector for > resolving > conflicts. Unfortunately we don't have a "conflicts" field in RPMs. So the > only > way to do this is by using "obsoletes". Kind of an open issue... > > Trimmed Packages table. It is clearly overdesigned since the opkg-* can't > transport all information which this was designed for. Main change (will > need code revies): the fields name, summary, package, description can > not be _all_ filled with info. Left "name" and removed "package". This > is the opkg name. Summary and description can be filled with info from > the native opkg-*. Added a distro field. This one should hold the target > distribution for the package. This string is the compatible distro > string, i.e. the name which a local oscar repository directory would have. > Example: rhel-5-x86_64. > > Now opkgs can show up several times in teh Packages table, the name is not > unique! Once for each distro for which they are registered. > Node_Package_Status > should point to the correct opkg. The reason for this is: > - opkgs can be supported on particular distros, only > - opkg versions for different distros can be different! > > This is a less invasive change that first approach and is in line with the > desire to use ODA:Packages as a globally cached view to the stuff available > in accessible repositories. This info can be outdated, the TRUE status > (availability, versions, etc...) is in the repositories!!! > > 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
