I'm really talking about two things, one of which is no problem.
1. being able to change compile time options
No problem, its already possible. Everyone agrees that you better know roughly what you're doing, or the package won't work.
2. being able to dynamically find & satisfy dependencies
Definitely a challenge, hasn't been solved yet.
If you put 1 & 2 together, then you have a software system that is highly customizable & yet easy to use.
In fact, Fink already partially does 2 -- every time it asks the user to choose between different ways of satisfying some dependency.
But I'm saying (as a class project or something) - throw an Expert System into Fink that will be able to map you from compile time options to dependencies, automatically (again leaving the user the choice as to how to satisfy a dependency when there's an overlap).
The problem is not in being able to dynamically find dependencies or change compile time options, it's being able to know whether the differences between it and a "normal" fink compile will work.
There are a *lot* 3rd-party-compiled bits that won't work right if you just link against them, instead of the Fink versions. It can be anywhere from different configure options, to libtool bugs, to having a different environment that introduces new bugs.
OpenDarwin is running into the same issues (they currently do something like you're suggesting) and they're moving to the Fink model of controlling what gets found precisely *because* there's too much entropy in assuming whatever libfoo that the user happens to have lying around will work.
It's software, I'm sure it's *possible* to do what you're suggesting, but it's a maintenance nightmare. Just witness the number of problems people post to the list about just because someone has an old dlcompat on their system from OpenOffice.
Just because it's possible for Fink the toolset to do it, doesn't mean it's possible for Fink the collective of maintainers to be capable of keeping up with every possible bug in every build of a particular bit of software. This is a volunteer effort; supporting such things just means we would have less packages with more bugs, in my opinion.
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
