So, the one part is to agree on a package format for all of this. But the other side of the coin of course is that all of this has to be implemented somehow, too (surprising, isn't it? <g>).
Some definitions first: I say a package is "multi target" if multiple binary (deb) packages are generated by it. I will call each of them "splitoff", except for the base one which I coin the "master". Let's assume we have a package "foo" with splitoffs named "shlibs", "bin" and "docs". So in the end we will have four packages built from this single description, namely the master "foo" and the three splitoff "foo-shlibs", "foo-bin" and "foo-docs. I) How to handle (re)building? ------------------------------ What if the user enters something like "fink rebuild foo-docs" ? What happens if a package depends on "foo-shlibs" which is not yet installed/built? One possibility is that inn such a case, all four targets of the package should be rebuilt. Reasoning: 1) It's cheap to do it 2) We must gurantee that the target packages are always in sync! e.g. a developer working on a package will "fink rebuild" it a lot, e.g. with changed ConfigureParams 3) It's probably the simplest to implement (more on this later) I can't really see any good reasons not to do it this way, however, I welcome any input on this. 2) How to represent this internally? ------------------------------------ Currently, when fink parses an .info file, it creates a hash (sort of a "structure" if you are not familiar with perl) for that package, containing all information on it (the compile/install/other scripts, the source URL, list of mirrors, description etc.) For splitoffs (and also for variants), we simply created additional hash entries, each represneting the splitoff/variant package. Variant packages are actually easier to do, since they represent full-blown packages of their own; the only special thing would be to add support to allow the user to steer which variant gets selected (by interaction or via entries in fink.conf). But we are talking about multi target packages right now. For those, we want splittoff packages. Now, a splitoff is not actually a full blown package; while it may have it's own description field etc., it won't have a compilescript. So what we will do is, we add one more internal package type (if you didn't know yet, internally fink uses a package type of value "dummy" for some purposes), e.g. "splitoff". Each "splitoff" package would also get a pointer to its master package (the one it will be split off from). Finally, the master package carries a list of all its splitoffs. When Fink now is asked to rebuild either one of the splitoffs or the master, it can automatically interfer the existance of the master/splitoff. It then proceeds to simply build the master, then create the splitoffs from that, and finally package all. Of course, one has to pay attention that if e.g. "fink rebuild foo-shlibs foo-docs" is entered, the stuff isn't rebuilt twice =). 3) File format to represent splitoffs ------------------------------------- A slightly extend version of my original demo. Note that the Splitoff: field is nonstandard since it mixes the single & multi line formats. Package: foo Version: 1.2.3 Revision: 1 Maintainer: Me Myself <[EMAIL PROTECTED]> Depends: bar-shlibs BuildDepends: bar 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) Description: Additional binaries for foo << SplitOff: shlibs << Files: %i/lib/libfoo*.dylib Shlibs: libfoo 1 foo DocFiles: README Recommends: %n-bin (= %v-%r), %n-docs (= %v-%r) Description: Shared libraries provided by foo << SplitOff: docs << Files: %i/share/mystuff/* DocFiles: README Recommends: %n-bin (= %v-%r), %n-shlibs (=%v-%r) Description: Documentation for foo << DocFiles: README Description: Grafels any blorg-barfer known to mankind. Homepage: http://www.example.com 4) Shlibs field --------------- We will still retain a shlibs field, but more how I meant it originally, i.e. basically a direct copy of the debian "shlibs" format. This allows us to have shlibs in multiple splitoffs, or you could even use it in a package that doesn't do splitoffs at all (no idea why one would do that, but then, I am not a seer :) 5) XML format ------------- As I stated before, an XML format is not needed for this. However, a lot of this stuff would indeed be easier to do with XML (or in YAML, for that), since both allow for multi level fields already. Comments, please! 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
