Ben Hines has asked me in private email why we need the "%n (>= %v-%r)" part of the new Shlibs field.
Although I can't give an example of this at the moment, I can explain some future scenarios where this will be used. Suppose that your package builds two shared libraries, libfoo.1.dylib and libbar.1.dylib, and that at some future time the major version number for libfoo is increased to 2, but libbar stays at version 1. What will you do? You will make pkg2-shlibs which contains libfoo.2.dylib and libbar.1.dylib, allow it to "Replace" pkg1-shlibs (so that libbar.1.dylib can be overwritten by the new version), and make pkg1-shlibs "Depend" on pkg2-shlibs so that any binary expecting to find libbar.1.dylib installed by pkg1-shlibs will still find it installed. But you will also revise pkg1-shlibs to say: Shlibs: << %p/lib/libfoo.1.dylib pkg1-shlibs (>= %v-%r) %p/lib/libbar.1.dylib pkg2-shlibs (>= 1.2-1) << This way, any packages compiled in the future which have libbar.1.dylib somewhere in their dependencies will be referred to pkg2-shlibs for the future rather than pkg1-shlibs. Another example would be a package with several variants which are producing functionally equivalent libraries. For example, it might be true that the libs produced by the giflib and libungif packages are completely equivalent. (I'm not sure if this is true, though.) If that is true, then the Shlibs field can say: Shlibs: << %p/lib/libfoo.1.dylib giflib (>= 1.0-1) | libungif (>= 1.0-1) << -- Dave ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
