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. > Also, a proposed extension to the info file format, variants, >requires a much improved system to be in place. Since my opinion on this is radically different to yours, I look forward to hear your reasons that back your statement. Again if possible please based on hard facts. Thanks. For completeness: I think implementing this inside Fink is not that hard (except that we haven't even finished designing it so it's impossible to judge with any final certainty). The major problem I observe is dpkg, which will not know about "variants", so we have to map Fink package variants to dpkg package names in some fashion, and that leads to trouble, because Fink package names won't match dpkg package names anymore. Maybe I miss something in the codebase that will pose a major hurdle to adding variants, and that would basically require a rewrite of Fink - since you apparently seem to think so, you certainly can explain these reasons to us, I at least am eager to learn about your findings. Also note that while we discussed the idea of variants on this list in the past, the idea and design were never even close to a state in which they could have been implemented, IMHO. > The recent storable-pm/indexing inclusion into Fink has alleviated >this third problem, that of speed, but in the future it will be >desirable to further increase the speed of the parser. Sure, speed is always good to have :-) > I would like to propose that the core of the fink parser be >rewritten to include all recently added features, and fix many of >the dependancy problems springing up from the shlibs project. Err, which problem would that be? Did you file bug reports on them yet? I only know about the old "problem", namely that we never implemented (Build)Conflicts in Fink directly, but what errors are there "springing up from the shlibs project" ? Again, please give me something concrete, I dunno really how to reply to you since everything is so extremely vague and without any facts to back it.. > I am willing to work on this for a while. It may not be an >immediate transition, but I would like to transition to a faster, >more bug free system. I also think that it the parser is rewritten, >it should be redone in C, C++, or Objective-C, whatever this list >decides upon. Anybody who wants to work on such a rewrite will have to discuss that. Cheers, 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
