At 11:37 Uhr -0500 30.01.2002, David R. Morrison wrote: >I'll take over as the new libpng maintainer (from chrisp). I made a fink >package for the latest upstream version. However, I have not put it on >CVS, because the major version number has changed and if you install the >new one, you will break around a dozen other packages which depend on it >(unless you recompile). I'll commit the new package to CVS after we have >finished adding shlibs support to fink (which should make those recompiles >unnecessary).
I need to clarify this, since there might be some misunderstandings on what shlibs actually means, and what it will mean to us and what it does *not* mean. Shlibs is a mechanism that allows a package to tell Fink what shared libs it provides, in which revision (and also since which revision that package supported this revision of the lib). Then the tool dpkg-shlibdeps (which I "ported" over to work on Darwin) scans binaries/libraries in a freshly created package for all their shared lib dependencies. It then compares those with the global database of all known shlibs dependencies (this is based of course on the set of installed packages). It then adds this information to the list of dependencies. Let me give an example: libtiff provides libtiff.3.dylib. Now if a package foo is using libtiff, then in the future, Fink will automatically detect this and add libtiff as a dependency to package foo's .deb files, even if the maintainer forgot to do so. it will also make sure that it depends on the right version. That's all to it. No magic. In particular, it won't keep older version of shared libs around while they are still needed. And it won't free you from having to recompile. Achieving that is a quite involved task indeed, since it means you have to keep parts of a package around (like libtiff.3.dylib), enve though the rest of the package is removed, creating "orphaned" files that nobody owns anymore, and that hence will start to heap up. So now one would have to come up with a scheme to work around that. For example, one could create on-the-fly some minipackages that care for these files. Or maybe keep a "database" that keeps track of these files, and will remove them once the last other package using those oudated .dylibs is removed. But be careful to not remove to early or hell will break loose. Also, this doesn't answer what happens if you later try to install a package that was build against an older version of libtiff (to stick to my original example) when only the new version is installed. Should fink now somehow try to get hold of that old .dylib file (nontrivial; e.g. it might have to build an old version of that package, which might not even be available)? Or should it just tell the user to rebuild? How does it know it has to rebuild, and that this special version of the dylib was needed by that binary? Ugh. There is about a shipload of pitfalls involved. I wonder if it is worth the effort. Just keep in mind: this is something different from "shlibs support". Max -- ----------------------------------------------- Max Horn Software Developer email: <mailto:[EMAIL PROTECTED]> phone: (+49) 6151-494890 _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
