Based on the discussion which Max and I had on this list yesterday, I have
drawn up a proposed new policy document for shared libraries in fink.
If we all agree on this, I would propose to add it to the packaging manual
as a new subsection 3.3 under Packaging Policy. Your feedback is most
welcome.
-- Dave
Shared Libraries
Fink has a new policy about shared libraries, effective in February 2002.
We first discuss the policy as applied to newly ported software, and
then turn to the question of upgrading existing fink packages. For an
example of the policy in action, see the recently added libpng and
libpng-shlibs packages in fink's unstable tree.
Software which has been ported to Darwin should build shared libraries (as
opposed to static libraries) whenever possible. When this has been done,
<b<two</b> closely related fink packages should be made, named foo
and foo-shlibs. At present, this must be done by hand, but an extension to
fink is under development which will allow both fink packages to be generated
from a single .info file having a new type: "shlibs."
Each software package for which shared libraries can be built must have
a <b>major version number</b> N. The major version number is only supposed
to change when a backwards-incompatible change in the library's API has been
made. Fink uses the following naming convention: if the upstream name
of the package is bar, then the fink packages are called barN and
barN-shlibs. (This is only strictly applied to new packages, or when the
major version number changes.)
The shared library itself and certain related files will be put into
the package barN-shlibs; the "include" files and certain other files will
be put into the package barN. There can be no overlapping files
between these two packages, and everything stored in barN-shlibs must have
a pathname which somehow includes the major version number N. In many
instances, your package will need some files at runtime which are
typically installed into %i/lib/bar/ or %i/share/bar/ ; you should
adjust the installation paths to %i/lib/bar/N/ or %i/share/bar/N/.
All other packages which depend on bar, major version N, will be asked to
use the dependencies
Depends: barN-shlibs
BuildDepends: barN
It will not be permitted for another package to depend on barN itself.
If your package includes both shared libraries and binary files, and
if the binary files need to be present at runtime (not just at build
time), then the binaries must be split off into a separate package.
When building shared libraries under major version N, it is important that
the "install_name" of the library be %p/lib/bar.N.dylib . (You can
find the install_name by running "otool -L" on your library.) The
actual library file should be installed at
%i/lib/bar.N.x.y.dylib
and your packages should create symbolic links
%i/lib/bar.N.dylib -> %p/lib/bar.N.x.y.dylib
%i/lib/bar.dylib -> %p/lib/bar.N.x.y.dylib
If the static library is also built, then it will be installed at
%i/lib/bar.a
These things are usually handled automatically by libtool, but you should
check that they have been done correctly in your case. You should also
check that current_version and compatibility_version were defined
appropriately for your shared libraries. (These are also shown with the
otool -L query.)
Files are then divided between the two packages as follows
in package barN-shlibs:
%i/lib/bar.N.x.y.dylib
%i/lib/bar.N.dylib -> %p/lib/bar.N.x.y.dylib
%i/lib/bar/N/*
%i/share/bar/N/*
%i/share/doc/barN-shlibs/*
in package barN
%i/include/*
%i/lib/bar.dylib -> %p/lib/bar.N.x.y.dylib
%i/lib/bar.a
%i/share/doc/barN/*
other files, if needed
Notice that both packages are required to have some documentation about
the license, but that the directories containing the DocFiles will be
different.
At the moment, the only way to do this is to let each package run the
original CompileScript and InstallScript, and then remove some of the files
prior to installation. (Notice that, as in the examples libpng,
libpng-shlibs, you may be able to use %v in place of N.x.y or x.y in
the .info file, which is more robust for updating minor versions of the
same package later on.) In the extension of fink under development,
you will be able to just specify which files are to be installed into
barN-shlibs rather than into barN.
There should be a dependency specifed in package barN:
Depends: barN-shlibs (= exact.version.of.barN)
and otherwise the dependencies in the two packages should be identical.
What to do when the major version number changes:
If the major version number changes from N to M, you will create two new
packages barM and barM-shlibs. The package barM-shlibs can have no
overlap with the package barN-shlibs, since many users will have both of
these installed simultaneously. In package barM, you should use dependencies
Conflicts: barN
Replaces: barN
and similarly, you should revise barN to include dependencies
Conflicts: barM
Replaces: barM
Users will then see barN and barM shuffling in and out as various other
packages are built which depend on one version or another of the shared
library, while barN-shlibs and barM-shlibs remain permanently installed.
How to upgrade an existing fink package:
For an existing fink package which installs either static or shared
libraries, the best way to upgrade is to create a new version foo of
your package, accompanied by a new package foo-shlibs, which satisfy
the above policy. If shared libraries (or any other files now present
in foo-shlibs) were installed previously, then these new packages should
say
Conflicts: foo (<< earliest.compliant.version)
Replaces: foo (<< earliest. compliant.version)
so that upgrading will be transparent to users.
After your upgrade, packages which say "Depends: foo" will continue to
function normally. However, you should contact the fink maintainers
of all such packages and urge them to modify their packages to say
"Depends: foo-shlibs, BuildDepends: foo" as soon as possible. You will
not be able to create new packages fooM, fooM-shlibs which implement a
new major version of the shared library until they have done so.
Existing fink packages which have not used the correct install_name or
which have not used the correct names or symbolic links for shared libraries
must be upgraded carefully, on a case-by-case basis. If you are
having trouble finding an upgrade strategy to make your packages compliant
with the new policy, please discuss it on the fink-devel mailing list.
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
