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

Reply via email to