Hi guys:
Currently I don't have time to follow this thread, but just want to
throw in my $0.02 worth.
If you are modifying the Selector GUI, please remember to also make
the same changes to the Selector CLI (unless you are modifying the
same code).
Some people (me included) make heavy use of the CLI.
Thanks!
Bernard
On 10/29/07, DongInn Kim <[EMAIL PROTECTED]> wrote:
> Hi Erich,
>
> > On Monday 29 October 2007 04:15, [EMAIL PROTECTED] wrote:
> >> Log:
> >> I am not really sure if this is what we really want to implement on
> >> Selector but this is a rough draft to make Selector a little more
> >> useful. Now Selector lists up all the packages which are available on
> >> the local and remote repositories. packages in Default package set
> >> are selected as usual. Still Selector uses oda to get the proper
> >> information and oda would be used only if data can not be queried from
> >> opkg meta repositories.
> >
> > I'd give up the ODA queries for package information. As far as I understand
> > we cannot fill ODA with config.xml data anyway, and it's not worth the
> > effort.
> > These changes only make sense if we simplify the code, and that means throw
> > out
> > ODA for package management. Only keep it for a list of opkg names and their
> > installation status.
> >
> Yeah, I would rather spend more time to simplify Selector to not use ODA as
> much as possible. Probably having config.xml information in oda does not hurt
> OSCAR. It would be just redundant. To be honest, since we use a new format
> config.xml and oda has not been fully updated for the new format, oda does
> not have all the information of config.xml yet.
>
> > ...
> >
> >> my $allPackages = SelectorUtils::getAllPackages();
> >> +# my @opkgs = OSCAR::OpkgDB::opkg_list_available(%scope);
> >
> > So are you ready for the switch over?
> Yes, I think it is pretty much ready to switch over to opkg-meta data.
> >
> >> # For each of the OSCAR packages read in above, add a "location"
> >> field
> >> # to correspond to the Location column of the packagesTable.
> >> + if( ! $allPackages->{$pack}{path} ){
> >> + $allPackages->{$pack}{path} = "/var/lib/oscar/packages/$pack";
> >> + }
> >> $allPackages->{$pack}{location} =
> >> (($allPackages->{$pack}{path} =~ /\/var\/lib\/oscar\/packages/) ?
> >> "OPD" : "OSCAR");
> >
> > This is kind of obsolete now. There is no practical difference between OPD
> > and OSCAR, so the location is uninteresting. All packages come from some
> > repository, so you can call them all OPD, or OSCAR. OPD is actually an
> > incorrect term now, there is no special "package download" any more. It's
> > all
> > "just" an install from a repository.
> >
> > I'd replace the content of the "location" field with the repository where
> > the
> > packages live on (not yet sure how to do that such that it works on debian,
> > too). And simply remove "location" and "path".
> Well, what about having the two paths for the remote and local repos?
> There may be some users who still want to download the oscar package tarballs
> including the opkg-meta data rpms.
> Then it would be much clearer if we have a tag to differentiate the local and
> remote repos.
> So, I would rather use "oscar" for the local repo and "opd" for the remote
> repo.
> FYI, the local path is not correct now. It is pointing to
> "$ENV{OSCAR_HOME}/packages/$PACKAGE_NAME" and it should be
> /tftpboot/oscar/$WHATEVER instead.
>
> Of course, if, in the future, we do not maintain the oscar packages tarballs
> but only remote repository instead, then the tag would not be really
> necessary because they are all from OPD.
>
> Regards,
>
> - DongInn
>
> -------------------------------------------------------------------------
> 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
