On Wednesday 31 October 2007 14:16, [EMAIL PROTECTED] wrote: > Quoting Erich Focht <[EMAIL PROTECTED]>: > > > On Wednesday 31 October 2007 12:34, Geoffroy Vallee wrote: > > > > > > On Wed, 2007-10-31 at 10:21 +0100, Erich Focht wrote: > > > > On Wednesday 31 October 2007 01:54, Geoffroy VALLEE wrote: > > > > > On Tuesday 30 October 2007, Erich Focht wrote: > > > > > > On Tuesday 30 October 2007 19:22, Geoffroy Vallee wrote: > > > > > > > On Tue, 2007-10-30 at 17:12 +0100, Erich Focht wrote: > > > > > > That works, but doesn't solve some things doable by prereqs easilly: > > > > > > removing some rpms and executing some (arbitrary) scripts. It can be > > done > > > > > > over the long term, but not in the next week. > > > > > > > > > > Yes but on this other side you are deeply modifying the OSCAR > > architecture > > > > > which mid-term will be pretty bad for other projects. Binary packages > > can > > > > > also give you conflicts and dependencies. Based on that i think it > > should be > > > > > pretty simple to implement what i propose. > > > > > > > > You proposed to stay with the current setup and I agreed. What is your > > problem? > > > > Can't you see that we're in wild agreement here? > > > > > > No you are changing the way OSCAR is working and you speak about a lot > > > of different issues at the time: you slowly move away the idea of using > > > OPD (for which the specification may differt but this is another story); > > > you put in SVN log comments about removing critical tables and so on. > > > > No from my side, too. OPD makes no sense any more. The role of OPD is to > > manage > > which repositories you present to your cluster and which not. OPD doesn't > > need to download any packages any more. You can keep its name, if you like > > it, > > and you can download opkgs and what belongs to them to some local > > repository, > > but that's all. You will never again need to manage /var/lib/oscar/packages/ > > content besides installing or removing opkg-API rpms/debs. > > > This is not my question and of course OPD will have to change, the first > definition (not the definition of OPD2 which is slightly different) is > suitable for OPKGC. But you still do not answer my question which, at > the end, is pretty clear.
Probably I simply cannot understand that you don't understand what I mean. The repository management capabilities I implemented into PackagePath.pm (which can be used manually with yume from the command line) are doing exactly what we want: offer the native package management system a way to access repositories from other contributors. The current implementation of Selector is using all the available repositories for building its table shown to the user. The abstraction presented is the SAME as it was before. Only the name of the function has changed. The function comes from OSCAR::OpkgDB instead of OSCAR::Database. Switching this function over is a matter of one minute, much shorter than the time wasted in this thread. As said before: if this method shows performance problems, we feed Packages by data from OSCAR::OpkgDB and switch over to OSCAR::Database. Done in 5 minutes. > > The comment in the svn log message is a reflection of my thoughts on the > > use of the Packages table. The fact that Packages only has a clear meaning > > on > > homogeneous clusters is currently recognized generally. There IS a problem > > with the way how we use it. There are many alternatives to change this and > > I will refrain from exposing them as they have the potential to ignite more > > of these useless controversies. > > Sorry but SVN logs are definitively NOT the place for thoughts. You > cannot put such things into logs, it is not the appropriate place. So we have a regulation for log messages style? Where? Does it contradict any freedom-of-speech rights? > > If you'd read the code I checked in you would notice that OpkgDB produces > > structures which are very close to what you extract from ODA. The changes > > from DongInn show that the Selector has to be modified only marginally in > > order to switch over to something else. I was trying to provide > > compatibility, though actually this is against what I understand under > > cleaning up. > > > You do not answer the question: will Selector still use data from the > database in order to produce the list of available OPKGs. You say that > the output is close to the ODA format, my question has nothing related > to that. You are changing the definition of abstractions into OSCAR, i > think this is not a good idea. Typically we all took care in the past to > use ODA has a basic component for all the other components. Why do you > want to change that? Why is not it possible to populate the database > before using Selector, i.e., the current approach? It is possible to populate the database. As explained above: the two ways of doing this are equivalent, only the data source is different. And we can switch back and forth, the only criterium is the quality of code and the performance. > > My comments on OPD remain valid. Until now selector was only dealing with > > local packages, therefore it needed OPD to get them from remote sites. This > > is not needed any more. If you rename OPD to something which describes what > > it still needs to do (manage repositories), you will see that selector > > wonderfully works together with that. > > Assuming Selector does not get info from ODA, yes. But it is exactly the > point i do not agree with. You still do not answer the question about > the abstraction Selector will use to get information about OPKGs. Once again: there are two ways, i.e. two possible abstractions, which actually aren't even ebstractions. They just are what they are: interfaces to read the same data: 1) info comes directly from native package mgmt by OSCAR::OpkgDB - this is simple - it might be slow but needs to be checked - it might be complicated when using multiple distributions in the same cluster 2) info is fed from native packager to ODA. Selector asks ODA through OSCAR::Database - uses 1) to collect info - info in ODA could be outdated, synchronization is a separate step - could be faster than 1), but not when we need to sync with repo data. - handling of multiple distros in same cluster is not cleanly designed & not implemented 1) is almost done. 2) needs some design work, but can be done quickly, too. 1) is the natural step before moving to 2) (if needed at all). > > > > And I have no intention to change that. > > No, actually I implemented changes in yume and PackagePath.pm to exactly do > > that, so in fact I am finishing your unfinished implementation of opd2. > > Don't you realize this? Last time we had this kind of struggle I was > > implementing rapt to help integrating debian. WTH! > > > This is not my question, don't you understand that? Since few weeks you > do not even answer my simple question: What abstraction Selector will > use to get info about OPKGs? Is it a so difficult question? Read the code or implement something. I wasted way too long time with this. Bye, 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
