On Wed, 2007-10-31 at 11:41 +0100, Erich Focht wrote: > 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.
I agree with that (and it does not imply erasing the table). > > > 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. I disagree with that, it is clear that with yume/rapt, we will never scale to few hundred nodes, especially based on the few tests i did with yum. > > > 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. I agree that OPD has a pretty bad term now (it is actually something that is more or less in the documentation on the Wiki). But again, back to my question (i am not the only one to ask the question, Thomas did too during the call 2 or 3 weeks ago). Why cannot we use OPD to populate the database after a query of the available OPKGs for a given or all distributions/architectures. > > 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.) I never disagree with that, i think this is a good point. > > - opkg-server for core packages are installed in the prepare wizard phase. > No change in logic or architecture here. Idem. > > - 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. I agree with that but it seems we disagree on the one to achieve this point (cf. my question about using OPD as an abstract to do so). > > - selected non core opkg-server packages are installed on the master, > opkg-client packages are installed in the image. I never disagree with that, i think this is a good point. > > 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). No because you only speak about the definition here. What about the questions i asked about where this is actually implemented? We need to be careful about how we implement abstractions between the different OSCAR components, that will impact the effort to develop future code and maintain the current code. Again, we (not only you, i started to do the same thing) start to put explicit usage of yum/apt commands in several places; i think it is pretty bad. > > Whether one uses the Packages table or a call to OpkgDB (implicitely querying > repositories), is not an architecture change, it is an IMPLEMENTATION DETAIL. No see my remarks and questions. Your implementation will change the way abstractions are currently defined. > 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. I never disagreed with that. > > 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
