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. > > 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. OPD2 is already very tiny, but this is not my actual point. > > > > 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. Sorry but SVN logs are definitively NOT the place for thoughts. You cannot put such things into logs, it is not the appropriate place. > > 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. But it is different from removing the Package table. > > > - 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. 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? > > 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. Ok. > > 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. > 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? And BTW rapt has nothing related to these points, please do not mix everything together. On a side note, personally since the beginning i think rapt/yume are not that useful; i clear definition of Packman with both Deb and RPM modules will do the same thing with only 1 component instead of 2 (something that was done in the previous version of OoD but that was trashed by other developers because other OSCAR developers did not discuss with me when they started to work on Debian stuff, but again this is another story, let's forget that and move forward). But this is another question and at the same time, rapt/yume are kind of stable so that's fine. > > > > > > 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 i think this is not enough, it is clear that you are modifying the Selector design without discussions. > 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?) No, PSM has nothing to do with that. PSM is the package set management system; the wiki is supposed to give a full description of what is OPM. If you have questions, we will be happy to answer and update the Wiki if needed. > 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... I do not care about that, these are only details > > 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
