As some of you know, I've converted a few existing fink packages to this new "shlibs" mode, and I've also been advocating that some other develoeprs do the same. As I've gained some experience with this, I've started to question the role of splitting off the binaries from the rest. (The idea to do that comes from Debian policy.) For libjpeg and libtiff I built three packages, but for gdbm and libpng I only built two (since there were no binaries).
This came up again just now when Ben Reed submitted a revision of one of his earlier packages (rrdtool) to the package submission tracker. Here's the conversation we had: Dave> Thanks for being the first one on the block to reformat! Dave> Dave> The binaries and perl modules are problematic. We're still Dave> experimenting with this, of course, and your input would Dave> be welcome. Dave> Dave> The idea is that rrdtool itself should basically only have Dave> headers, static libraries, and the non-versioned dylib link. Dave> That way, if somebody later changes the API and we have to Dave> make rrdtool2, you'll be able to leave both rrdtool-shlibs Dave> and rrdtool2-shlibs resident on the system at the same Dave> time, and swap rrdtool and rrdtool2 in and out. Dave> Dave> So nothing should ever Depend on rrdtool itself (because Dave> that would prevent the swapping), and that's Dave> why I was recommending (as the debian system recommends) Dave> splitting binaries, perl scripts, whatever off into a Dave> separate package, in your case rrdtool-bin. I did this Dave> with libjpeg (didn't have to do it with libpng because Dave> there were no binaries). Does that make sense, or am I Dave> missing something? Ben> Yeah, I saw the -bin thing, but didn't know if that applied, Ben> since "rrdtool" is an application binary as well as a Ben> library. I had assumed that the -bin package was for Ben> ancillary utils that are part of a library package. But, Ben> rrdtool is in that kind of limbo where it's used just as Ben> equally in both ways, so saying "it's a library" or "it's an Ben> application" are both just as right. Ben> Ben> We can continue this on -devel if you want, but I can see Ben> arguments for both ways. Whatever you think makes the most Ben> sense is fine with me; if it keeps things tidy to split -bin Ben> I can do that. RRDTool is picky and builds it's bins Ben> statically anyways. I gave the argument for making the split above. Here's an argument for NOT splitting: after all, a lot of this pkg/pkg-shlibs split is designed to accomodate a future library revision, which may or may not ever take place. In that future library revision, the binaries will probably also be provided. So, although it might increase dpkg's time in swapping things in and out, the basic non-shlibs package could contain a bunch of other stuff like binaries. A problem would only arise if some other package wanted to verify that the binaries were present, not just the libraries. If that is the case, then the binaries will have to be split out for that package. I would like to hear the thoughts of others on this question. I hope the issue is clear. -- Dave _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
