Jack Howarth wrote: []
If fink's dpkg weren't so brain dead about shared library versioning
While you have IMHO correctly diagnosed the idiocy of freeglut using the same name libglut.3.dylib as the old glut when it is not a binary compatible dropin replacement, you are certainly barking up the wrong tree here.
I could do that and then use a correctly different version for the glut
produced by freeglut (it really should be libglut.11.dylib anyway).
However dpkg in fink seems unable to detect whether a package has a
dependency on libglut.3.dylib or libglut.11.dylib when a package is installed. So that option is out as well.
Until now (this may change in the future), Fink packages do not depend on library files or versions thereof, they depend on other Fink packages. So your statement does not make sense. Binaries OTOH, linked with one of the libglut dylibs will know exactly which one they were linked with, provided the install_name of the dylib is correct (which it probably isn't in your version).
No matter what I do all the packages that use glut will need to be rebuilt so you might as well follow Redhat and Debian's lead and just toss out glut as of 10.4.
I do still not understand why you don't want to follow one of the established ways of adding a package with a new version of a library to Fink. The packages using the old glut have no need to be rebuilt if you do one of the following two things:
1. (This is what has been proposed to you several times in this collection of threads): Put the freeglut dylibs into a separate directory and *most important* make their install_name reflect this path.
2. (This corresponds to what you seem to have in mind but did not implement correctly, and it corresponds to the situation of other packages like db3/db4 or libdvdnav/libdvdnav2 etc): Change the name *and the install_name* of the freeglut dylib to /sw/lib/libglut.11.dylib.
In both cases, you don't touch the old libglut package except for a Conflicts/Replaces of the glut-dev and freeglut-dev packages which both will contain /sw/lib/libglut.dylib as a symlink to the respective real files. In both cases, the *-shlibs packages do not Conflict/Replace. They coexist.
-- Martin
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Fink-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fink-devel
