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.

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).
- 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.

> 
> > 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).


-------------------------------------------------------------------------
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

Reply via email to