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. So: I don't slowly want to remove the idea of using OPD, this was done by moving to repositories. At it is good, because it has a simpler logic, it treats all packages the same way, no matter where they are. We don't need to implement code for downloading opkg content, the package managers do that for us. And we can throw away useless code. Fight bit-rot. > So please can you answer these two questions for which it seems you are > your view of the problem and all the others another view (which may > differ); note that you never gave a clear answer to these questions even > during the calls: > - Do you plan to remove other tables, such as Packages, as you start to > speak about in the SVN log of r6381 (something you speak about since at > least one year and point on which the majority of other developers do > not agree on). 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. By the way: looking at the database schema makes me think that the only reason why removing Packages is bad, is because the Packages_Nodes_Status entries are using a package_id instead of an opkg name and because the entries are cascaded to the Packages table entries. None of these is really difficult to change. > - Why cannot we use OPD to implement an abstraction between the > repositories and ODA? Doing so, Selector can still be based on ODA, > minor modifications are required to port it to the changes implied by > OPKGC; and modification to OPD to go that way are pretty simple to > implement especially if Packman can provide a clean interfaces for > binary package query (again a good abstraction). Current we start to put > dpkg/apt and yum/yume commands in a several locations of the code; i > think this is not good. 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. Yes, I agree, Packman would be a desirable abstraction. And when I find time, I want to add the functionality which I added to yume to packman, too. Under the hood packman will still call yume/rapt. This will be another step of cleaning up which will break code and I can almost hear the screams... But yes, Packman is what I aim at over the long term. 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. 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! > > > Sorry but it works pretty well on Debian (i do not say it is perfect). > > > RPM > > > developers have been inactive, this is another problem. Do not generalize > > > your situation. > > > And why you do not like this idea. Without a clear explanation, sorry > > > your > > > point of view cannot be accepted. > > > BTW, i has ready to explain my latest developments and try to federate > > > efforts. Do you try to communicate with me? If do not think so... > > > > Read the other emails. I don't need this kind of crap. > > What? you say trunk was broken for months, i only say that at least on > Debian the situation is not so bad. Then i think you "missed" some > points because we did not have the chance to really chat about stuff > Jean and I were doing, you did not even ask me if i had code to complete > so stuff even if i told you several times that i have other pieces of > code which are not in trunk in order to extend OPD. Stop to interpret > what i say, please. > And again, it seems to me you will modify pretty deeply Selector in > order to be able to "directly query" the list of available OPKGs. I > think this is not a good idea; as i said before Selector should continue > to be based on ODA (i spoke about that during the calls). No, this will not happen, your worries are without reason. I will not modify deeply Selector. The interfaces are compatible. And we must finally approach and solve problems like how to select what should be installed on a particular subcluster and how to manage that. The purely CLI approach (is it called psm?) is IMO not really finished. The approach is more or less fine, but adds another place outside ODA where selections and package lists are stored. Another story... 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
