On Wednesday, May 29, 2002, at 05:42 PM, Max Horn wrote:
> At 16:47 Uhr -0400 29.05.2002, Kyle Moffett wrote: >> The most frequently occurring problem is the lack of Fink >> implementation of the Conflicts field. It is currently only >> implemented by dpkg. Here is an example of a problem: > I mentioned this in my mail, too. It is *one* problem. I still think > that your conclusion from this is still wrong. That is true, there is only the one problem right now, but if we continue to add features, we will certainly encounter more. >> This is somewhat complex to resolve, but I believe that I have a >> solution that will allow us to add further features as the occasion >> warrants. > > [...] > >> I realize that this is not very efficient, but simplifications can be >> worked on during the potential rewrite. (Also, the choice of a >> compiled language could speed things up.) > > Kyle, did you effer do graph theory, or anything related to graphs? > Your explanation doesn't sound as if that was the case, but I don't > want to do you wrong :-) Graphs (not trees, which are not sufficient > to represnt the full depends/conflicts structure) are how this has to > be handled (and dpkg/apt use them). No, I must admit that I have not. :-( > Note that was you described (a tree) is equivalent to what Fink > currentl does, only that Fink stores the tree in a list, in > breadth-first-travesal order. Hmm, maybe I should go read the code a little more, but I think some shortcuts were made in the algorithm that make it difficult to work with some additional features. > I have thought about changing the deps calulation code in Fink to be > based on a direct graph structure for some time now. Each package > represents a node, each dependency (note that dependency includes > (Build)Depends and (Build)Conflicts) is an edge. > We could and should rip the logic on how to handle this graph from the > dpkg/apt code, in order to stay fully compatible to them. I could go > into much more detail here now but my time is limited, but feel free to > ask for details. Yes, that would work well, but I better like your suggestion for linking with their libraries (If it works :-) > Alas, again what you say justifies my opinion: yes this needs > improvement. No this doesn't mean Fink "breaks down". I was exaggerating a lot, the problems are not that severe. However, I do find them annoying :-) >> That is true, the design phase is not complete, but I think that like >> the splitoffs project, problems will crop up in the current >> implementation of the parser. > > Note that the splitoffs had been fairly well designed before they were > first implemented. For variants, several fundamental problems are not > yet resolved, most importantly the issue I mentioned in my previous > mail: how to map variants to dpkg package names. I have not thought a lot about this, but perhaps by sorting variant names alphabetically and concencating them with dashes. (I think this was proposed before) >> I believe that rewriting the parser will allow us to find and solve >> many hidden, existing problems. > > What has the parser to do with this??? Or do you refer to the > dep-resolving code again? Well, that code in Fink (which is only one > part of many) could need improvement, yes, and possibly a complete > rewrite, agreed. Sorry, I did mean the dep-resolving code. >> However, I believe that with proper care, much of the existing code >> can still be reused > Now that sounds radically different from what you said before :-). So > Fink is not a complete mess but only one part has to be rewritten - and > I do agree with you that the dep resolve code could use an overhaul. What I meant was that if we were to rewrite the dep-resolver code in C, C++ or ObjC, we could reuse most of the other code for listing and the actual compilation. >> (Replace much of the Perl code in the parser with a C perlmod or io >> with an external program. > Note that a lot of time is not actually spent on parsing but for Disk > I/O and the slow OS X file system. I doubt that a C implementation will > gain us much. Yet again, I accidentally swapped the terms parser and dep-resolver > But what *would* be interesting was if we used the libs provided by apt > and used the dependency code in there. This way we would be > automatically 100% compatible to it. Of course this would require the > ability to feed our own data into it. This might be a worthwhile thing > to do, and probably better than rewriting this code - after all apt > already clones dpkg's dep code, so if we could use it that would be > better than cloning it again. Yes, that would probably work better (and be more compatable too). > I will be happy to look into this together with you. I am not intersted > in rewriting any other parts of Fink in C/C++/ObjC, though, since I > don't see anything to gain (besides a little bit speed, and that only > in theory), but also because I believe it will be harder to maintain. > That said, nobody will stop you from tackling this yourself, if it's > well done it sure has a chance to get back into Fink's main code base. I was only thinking of the dep resolver. Thanks for your time, Kyle Moffett _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
