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:
fink needs help picking an alternative to satisfy a virtual dependency. The
candidates:
(1) gnome-vfs-shlibs: The GNOME virtual file-system libraries
(2) gnome-vfs-ssl-shlibs: The GNOME virtual file-system libraries, with SSL
support
Pick one: [1] 2
The following 2 packages will be installed or updated:
dlcompat gnome-vfs
The following additional package will be installed:
gnome-vfs-ssl-shlibs
Do you want to continue? [Y/n]
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. The problems arise from the way Fink resolves dependencies. When building, it starts with an empty list, then fills it with dependencies from all the packages provided. Then it creates an array with all needed non-virtual packages, and prompts for the virtual ones (If there is a choice). I believe that this approach is problematic, as limits future growth and addition of new dependency complexities (Variants, splitoffs).
I would recommend replacing the initial structure with a tree, allowing us to resolve somewhat complex dependencies (Like some variants would be) simply and easily. The top of the tree would be the package to be installed. Each package in the tree would have an associated action ('Depends', 'BuildDepends','Conflicts',etc.), and underneath it would be all splitoffs (Or a similar thing for variants). Underneath each splitoff are all packages depended on by that splitoff, etc.
Then once the tree is created, simplify it into an array with a depth first transversal. Once the array is filled, the virtual dependency checker would be called to request virtual dependency choices, while being careful not to create conflicts. Other checkers could be added in this phase too. That section would repeat the tree creation and simplification until all checkers (Just the virtual dependency checker now) had finished. Then it would proceed to install the packages.
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.)
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.
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. I believe that rewriting the parser will allow us to find and solve many hidden, existing problems.
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..
Sorry for the exclusion, please examine the Fink output earlier in this email. (This has already been filed as a bug report, I think) At present there is only one glitch, but I do think that the non implementation of (Build)Conflicts will continue to cause problems as we add features and packages become more complex.
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.
However, I believe that with proper care, much of the existing code can still be reused (Replace much of the Perl code in the parser with a C perlmod or io with an external program.
Cheers,
Max
-- -----------------------------------------------
Max Horn
Software Developer
email: <mailto:[EMAIL PROTECTED]>
phone: (+49) 6151-494890
Thanks,
Kyle Moffett
