On Sun, Mar 21, 2010 at 04:49:11PM +0100, Vincent Beffara wrote: > > > For consitstency, I chose to use libipe.7.dylib as install_name > > > and so ipe7-shlibs as corresponding package name. The actual > > > software does not really do anything about it (without a patch the > > > install_name ends up being ../../build/src/libipe.so.5.0.10 or > > > something like that). > > > > I'd recommend being consistent with _upstream_ then, and setting the > > install_name as libipe.5.dylib. > > Ooops, I meant libipe.so.7.0.10 of course ! > > > > BTW, if ipe7-shlib is a splitoff of ipe, and there is an upgrade of > > > ipe upstream with a different major version, and I end up having > > > ipe8-shlibs as a splitoff of a new version of ipe, then nobody can > > > build ipe7-shlibs anymore, which sounds a little bad. So I will go > > > for ipe7 as package name. > > > > No, it should still be possible to build ipe7-shlibs. One way to do it > > is to have the version number on the .info file. > > Ah, I hadn't thought of that. So I do ipe7.info declaring ipe (with > version 7.x.y) and ipe7-shlibs as a splitoff, and if ever necessary > I will do ipe8.info declaring ipe again (with version 8.x.y) and > ipe8-shlibs as a splitoff, and Fink will not be confused by two > descriptions of ipe in two different files. That makes a lot of sense, > actually.
Ooh wait, is "ipe" the headers used for building against the "ipeX-shlibs" package? If so, the headers package must never change which -shlibs it's associated with. Otherwise, other packages that want to use ipe won't be able to control or know which library they get. imagemagick is an interesting example because it has a set of runtime programs in a package whose name never changes (because "which library those programs use" is hidden from the user of the programs) and then separate headers and libraries packages, whose names are tied to each other and do change when the install_name does. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ 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
