On Wednesday 31 October 2007 02:29, Geoffroy VALLEE wrote:
> I read again my email and i realized that i was really unclear and i did few
> mistakes (wrote the email too quickly):
> 1/ you did not erase the Package table, you are only speaking about removing
> the Package table and i think this is a pretty bad idea.
Indeed. And actually I reverted the change and moved it to a branch.
The Packages table as it is is not really useful on multi-arch or multi-distro
clusters. On those you can have different packages on different images, and
they can be different from the master. So the Packages table should contain a
superset of all packages (of all distros). But there is still no way to specify
on which distro you have which opkg. In that sense: this needs a redesign.
> 2/ i continue to think that the usage of yum/apt to grab information on
> remote
> nodes is a pretty bad idea at least in medium or large systems (slow and not
> scalable at all).
I tried with the gforge online repository and with the local ones. Under RPM
based distros this was fast enough. But I agree that this is a potential
performance problem. But it is unclear to me when we'd want to synchronize
with the online repositories.
> 3/ you change the way Selector and OPD will work without discussions, i do
> not
> think this is reasonable.
I don't. We discussed this in the last two calls. Remember Thomas' suggestion
to run the "setup" API script _after_ the Selector call? Besides, discussion
happens over the mailing lists and it was there. Since the opkgc idea came up,
we were discussing quite a lot.
In my opinion OPD has become a wrong term. With the introduction of opkgc
OSCAR Package Downloader (OPD) is still used as a term. But its meaning is
completely different from before. We are not required to "download" any
OSCAR packages any more. We just need to identify them and install them.
The only "download" process I can imagine is to create a local copy of a remote
repository. I am not changing the OPD logic or its meaning, it was changed by
opkgc. And you contributed significantly to that.
The Selector logic needs to be changed in order to get stuff running again.
Once again:
- opkg-API metapackages get installed _after_ the Selector
(I actually wanted to do it before, that would speed up all OpkgDB operations
and would really help removing the Packages table, but in one of the
previous
calls the opinion of Thomas (at least he was actively arguing) was that we
should install them late. You need more examples of discussion? There are
many.)
- opkg-server for core packages are installed in the prepare wizard phase.
No change in logic or architecture here.
- The selector displays ALL opkgs reachable via configured repositories. The
installers know how to deal with remote repositores and it seems useless to
distinguish between local and remote ones. Or between remote and very remote.
We have no logic in the selector to display where an opkg comes from, but
this is what we need to add.
- selected non core opkg-server packages are installed on the master,
opkg-client packages are installed in the image.
I see no change in architecture! This is EXACTLY what we were doing before!
With a small adaptation in the first point. An adaptation to changes we all
agreed upon (the switch to opkgc metapackages).
Whether one uses the Packages table or a call to OpkgDB (implicitely querying
repositories), is not an architecture change, it is an IMPLEMENTATION DETAIL.
Which can be optimized, once we have an implementation at all. Fixing calls
throughout the code is a chance to think once again about the implementation
details and clean up dirt that was collected over the years.
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
