Max, your new gdk-pixbuf package seems to have fixed all of the problems.
Thanks!

However, the current structure of this package does raise an important
question about the shared libraries policy.  gdk-pixbuf has a bunch of
shared objects (foo.so), which are different from shared libraries.
If I understand correctly, we can't include these in the versioning
system: otool -L doesn't report versions for them, and so on.  So
probably they should be treated like binaries rather than like libraries?

In the present package, numbers have been given to these shared objects,
and symlinks have been set up from unnumbered to numbered versions.
Presumably this was done by libtool.  But since the objects are never invoked
with -l in a compile setting, the symlinks don't serve their usual
purpose.  And since the MACH data as probed by otool doesn't include
numbers, we won't be able to store several different numbered versions
on the system and let the dpkg/shlibs tools take care of updating.

So I would think that this package should be split into three pieces,
maybe the third one to be called gdk-pixbuf-loaders.  It would be treated
like the binaries are treated in some other pakcages.  Splitting it off gives
the possibility of allowing the dkpg/shlibs system to install multiple
versioned copies of the dylibs, without getting conflicts between .so
files.

The other option would be to move the symlinks for .so files from
gdk-pixbuf-shlibs back to the main gdk-pixbuf package.  But as I tried to
explain above, I'm not sure that this makes sense.

Any thoughts on this?

  -- Dave



_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to