OK, folks, let me set some things straight once more:
1) No, this change is not made easier if we move at the same time to a new package format. I tried to explain it several times in the past: any new package format would almost entierly be transparent to the "backend" of fink, and only require new "frontends". I say "almost", because some additional information has to be handed on to the backend, describing how variouas variants of a package interact. Anyway, this is not the topic of my mail so I won't dive deeper into this right now. 2) Variants != multiple binary support. I said it before. These are orthogonal things. 3) I agree, we should allow multiple (compared to just two) binaries being build from a single info file. And yeah, the debian tools allow that via an appropriate control file, but one of the points behing Fink is to abstract all this and make it much easier to create & maintain packages. But I am not sure we should aim at this right now. The keyword here is: Step-by-step. If we change to many things at once, we will get lost. That is the same reason why I don't want to introduce a new package format just at the same time. In so far, I fully agree with David, so I cite him here: At 5:13 Uhr -0500 14.02.2002, David R. Morrison wrote: >There are two things to consider: > 1) most of the packages with shared libraries can get away with generating > only two debs, at least in the short run. We need to get packages > converted to that format as quickly as we can, because (as I found > out in the case of libpng) the more other packages that depend on > a given package, the harder it is to disentagle things to the point > where the shared libraries policy does some good > 2) the modifications that need to be made to fink should be done in a > way that generalizes to more than two debs, and maybe they should > only be done once. but of course, if we can come up with a way that makes full multi-bin support easy, we can go for it directly. Regarding the actual proposal: a) Depends like Depends: audiofile-shlibs (= 0.2.3-3) won't have to be specified explicitly, they will be added implicitly. b) The Shlibs in fact was not just meant to list files that ought to be copied into the -shlibs sub-package. Rather, it was meant to provide a mapping resembling that of the "shlibs" file debian uses. As such, it should be table that reads like libname revision dependency E.g. libfoo 1 foo (<< 2.0) libfoo 2 foo (>= 2.0) This will be used to auto-compute dependencies. c) To extend the original proposal to allow arbitrary multi-bin support, how about a format like the following (based on Peter's fake .info file, so you can compare with it). Note that I will refer to each "sub-package" as split-off-variant, or just splitoff. Also note that the following is not actually acceptable as a format, but should be good enough to demonstrate my idea. Package: mystuff Version: 1.2.3 Revision: 1 Maintainer: Me Myself <[EMAIL PROTECTED]> Depends: myotherstuff-shlibs BuildDepends: myotherstuff Recommends: %n-bin (= %v-%r), %n-docs (= %v-%r) Source: http://www.example.com/mystuff.tar.gz SplitOff: bin << Files: %i/bin/* Depends: %n-shlibs (= %v-%r) DocFiles: README Recommends: %n-docs (= %v-%r) << SplitOff: shlibs << Files: %i/lib/libmylib-1.2.3.dylib %i/lib/libmystuff-1.2.3. DocFiles: README Recommends: %n-bin (= %v-%r), %n-docs (= %v-%r) << SplitOff: docs << Files: %i/share/mystuff/* DocFiles: README Recommends: %n-bin (= %v-%r), %n-shlibs (=%v-%r) << DocFiles: README Homepage: http://www.example.com Note that splitoffs never share any files; the only files that can exist in all of the them are those specified with DocFiles. but even these end up in different directories. Cheers, 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
