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
