Hi. The most minimal form of implementing shlibs just divides the package in half, with pkg-shlibs containing libpkg.N.x.y.dylib, libpkg.N.dylib and often nothing else. (In particular, libpkg.dylib belongs in pkg, not pkk-shlibs.) It is OK to put /sw/share/pkg/N/* in there as well, so long as the major version number N occurs in the name.
What will happen is that at compile time, users will have both pkg and pkg-shlibs installed, but at runtime, they might only have pkg-shlibs installed. SO, if there are userland binaries as well as libraries, they could be put in a separate package. But it might not be necessary, it depends on your package. At some time in the future, when your package's major version number changes to M, there will be four packages: pkg, pkg-shlib, pkgM, pkgM-shlibs. It's OK to have the binaries in both pkg and pkgM, assuming that these two packages will get shuffled back and forth by users. However, if those two sets of binaries are not compatible, this might not be a good idea. I think the important thing for the moment is to get the pkg/pkg-shlibs split made, and get all other package maintainers to change their dependencies. That way, when the upstream authors change the major version number, you will be ready for a smooth transition. Actually, at that time you could decide to separate out the binaries, if they are overlapping between the packages. A good example of two major versions which does NOT separate binaries is libpng and libpng3. (Well, actually there aren't any binaries!) An example which DOES is db3 and db4 (and there, lots of stuff gets separated because the maintainer decided to do that). I hope this was clear; if not, please ask again. -- Dave _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
