On 9/29/10 6:53 PM, David R. Morrison wrote: > > On Sep 30, 2010, at 7:45 AM, Alexander Hansen wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 9/29/10 5:08 PM, Ebrahim Mayat wrote: >>> Hello list >>> >>> With reference to my submission (#3074237) for fluidsynth-1.1.2, I have >>> come across a compatibility version issue. >>> >>> As similarly outlined in my earlier message: >>> >>> <http://thread.gmane.org/gmane.os.macosx.fink.devel/19813/focus=19816> >>> >>> using autotools for the previous version of fluidsynth-1.1.1, the >>> compatibility version for the shared library libfluidsynth.1.dylib is >>> >>>> /sw/lib/libfluidsynth.1.dylib (compatibility version 5.0.0, current >>>> version 5.0.0) >>> >>> while building with cmake for fluidsynth-1.1.2 gives >>> >>>> /sw/lib/libfluidsynth.1.dylib (compatibility version 1.0.0, current >>>> version 1.4.0) >>> >>> So, this leads to a problem since the compatibility version is being >>> downgraded. The reviewer has suggested that this problem can be >>> circumvented by simply renaming the package. >>> For example, instead of "fluidsynth" the new package can be called >>> "fluidsynth1". This would seem simple enough but perhaps some of you >>> may have alternative ideas that should be considered. >>> >>> I would appreciate any suggestions on how I could effectively deal with >>> this compatibility version problem. >>> >>> Sincerely, >>> Ebrahim >>> >>> >>> >>> >> >> That's probably the most straightforward way to handle the situation. >> You'd want to have fluidsynth1-dev and fluidsynth-dev Conflict and >> Replace each other, of course. >> > > I'm afraid this case is trickier than that, because the major version of the > library has not changed and therefore the primary filename of the shared > library has not changed. So the files in the two -shlibs splitoffs will > conflict, and you can't use one to replace the other or the compatibility > version will break. > > Would it be possible to go back to using autotools to compile the package? > If not, you are going to have to modify the cmake procedures so that they > produce compatibility versions in the same way as the old autotools build > method did. Since I know very little about cmake, I can't give advice about > how to do this.
Speex had a similar issue recently (offloaded public but unstable symbols to another dylib) but kept the install name the same. The new speex version was put into a new package name (speex3 -> libspeex1) *AND* the libraries were put into a 'hidden' directory /sw/lib/libspeex1/lib (that is, not directly into /sw/lib) to avoid filename collisions while maintaining Shlibs policy. Hanspeter ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
