> An example is the "neon" package. Currently we are using neon24, but > in the recent past we used neon23 (and many earlier ones). If you have > neon24 installed and link with -lneon, you will be linked to the > v. 24 of the neon lib because of a symlink from libneon.dylib to > libneon.24.dylib. On the other hand, if you have neon23 installed > and link with -lneon you get v. 23 because of a symlink in that package > from libneon.dylib to libneon.23.dylib. > > For this reason, you have to be able to remove neon24 and replace it with > neon23, or vice versa. BUT, if other things are allowed to depend on > this package, then the removal will not be possible: you can only > remove something using fink (or dpkg) if nothing else depends on it.
Let A a library depending on neon. If A-shlibs and A-dev has been built with neon23, A-dev and neon24 should not be installed at the same time. If both were installed, binary inconsistency happens: gcc -o B B.o -lA -lneon If B did not directly refer any neon's symbols, gcc -o B B.o -lA -lneon would work. But GNU libtool's dependency resolution breaks this. GNU libtool knows A depends on neon from libA.la and appends -lneon. glibtool gcc -o B B.lo -lA -> gcc -o B B.o -lA -lneon Only way to avoid this problem is to disallow A-dev and neon24 to coexist. A-dev should Conflict with neon24 or Depend on neon23. As you wrote it breaks fink build anything-using-neon24. I suggest AllowRemovalOnBuild flag to let fink remove conflicting packages such as A-dev. ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
