Hi Martin. I'm sorry that the backward-compatibility has not been perfect. But let me remind you about what we are solving with the splitting up of packages.
An excellent example is provided by gal. gal is under rapid development, and new versions (gal-17, gal-18, gal-19) are *not* backward-compatible. So as you probably know, each time Masanori has updated to the latest version, every package depending on gal had to be rebuilt. The solution (it is the same solution that debian uses) is to provide a package which contains only the gal-18 or gal-19 or gal-20 shared libraries, and to guarantee that everything in that package has the number 18, 19 or 20 somewhere in its pathname. That way, all of these libraries can be installed simultaneously, and you can use various other packages which depend on them, without rebuilding (until the maintainer of the other package updates from gal-19 to gal-20, say). Now to get the building to work out right, there has to be a second package for each of these, which contains headers and also a key symbolic link associating the unnumbered gal library to the correctly numbered one. (That way, at link time the correct version of the library is linked in.) These packages all conflict with each other, so we can't allow any other package to depend on them. To try to get backward-compatibility to work, we are using the original package name for this header package, and the "-shlibs" name for the library package. The difficulty comes when something else, like binaries, also needs to be installed at runtime. That's when we get to a third package, and I agree that it is awkward, especially for backward-compatibility. We need the third package, though, because the binaries won't have the version number in their pathnames so they can't go with the libraries, and other things might depend on them so they can't go with the headers. I guess we need to be particularly careful in these cases that we get other packages changed ASAP to include the dependence on foo-bin. In fact, a conservative strategy would be to introduce a package foo-bin which was basically empty, convince all other developers to include it as a dependency, and *then* do the pacakge-splitting business. But that really shouldn't be necessary, we should be able to fix these things as they come up. -- Dave _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
