At 16:47 Uhr -0400 29.05.2002, Kyle Moffett wrote: > On Tuesday, May 28, 2002, at 08:14 PM, Max Horn wrote: > >>At 18:26 Uhr -0400 28.05.2002, Kyle Moffett wrote: >>>I have been extensively looking at the Fink coding and Perl >>>scripts/libraries, and I think I have an idea. I believe that >>>much of the Fink code needs an overhaul. The whole dependancy >>>system is starting to break down. (See recent threads involving >>>splitoff/shared libs problems) >> >>Wow. That's a gross statement. Yes there are problems, but deducing >>from this that "the whole dependancy system is starting to break >>down" ? That's a rather bold statement, esp. since you give no fact >>at all - may well be you "extensively looked" at the code, but can >>you please give proper justifications for that assertion, based on >>the actual code base? I.e. I much prefer facts over claims. > >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. [...] > >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). 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. 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. Alas, again what you say justifies my opinion: yes this needs improvement. No this doesn't mean Fink "breaks down". [...] >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 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. >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. >(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. T 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. 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. Max -- ----------------------------------------------- Max Horn Software Developer email: <mailto:[EMAIL PROTECTED]> phone: (+49) 6151-494890 _______________________________________________________________ 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
