At 18:11 Uhr -0500 02.02.2002, David R. Morrison wrote: >Hmmmm... I'm confused about the dependency relationships between foo-shlibs >and foo (using your terminology, Max). > >Do we say that foo depends on foo-shlibs? I guess that is OK; foo-shlibs >is going to have to load the entire source to get built, anyway, so there >is no point in have it BuildDepends on foo (which is what I was thinking >would happen).
In fact, what I was saying was that both are built *at the same time*. I.e. one build process is done. But in the end, some files are extraced, and put into a seperated package (foo-shlib). >There is one other issue: sometimes, there are a bunch of auxiliary >files which belong to a particular version of the library, and which >could get stored in /sw/lib/foo/N/ or in /sw/share/foo/N/. As long >as the N is there, these can go in the foo-shlibs package, right? >And in many cases they should So the syntax of the Shlibs: field will need >to allow for this. Yeah you are right. That's why Kyle is correct when he says that a new package format would ease all of this :) >The DocFiles, or anything in /sw/share/doc/%n, should also go in the >foo-shlibs package. Aye. > (In fact, I would be in favor of the following rule: >if you are using the Shlibs: field, then you put all the documentation >in /sw/share/doc/foo-shlibs, and you do not create /sw/share/doc/foo. >WHOOPS - see below.) > >I would suggest, maybe, a list of files that are supposed to get moved >from foo to foo-shlibs for installation. Anything put in by DocFiles >would be included, as well as whatever we list in Shlibs. The one tricky >part is that DocFiles has been interpreted as creating a single directory >with all of the files in it, but with Shlibs we need to preserve the >heierarchy. > >So, for example: > >Shlibs: << > %i/lib/foo.1.2.3.dylib > %i/lib/foo.1.dylib > %i/lib/foo/1/* > %i/share/doc/%n/* ><< > >(It's clear what fink is supposed to do here... InfoFiles and Daemonic >would belong to foo, not foo-shlibs, I think.) The LICENSE/COPYING/whatever file should be in both packages, ultimatly. >The WHOOPS above is this: the value of %n is foo, not foo-shlibs. So I >think that we are creating %i/share/doc/%n not %i/share/doc/%n-shlibs. >Either that, or we have to duplicate the documentation between the >two packages, which seems silly. I am not sure if this is silly. Sure, duplicating a full manual is silly, but when it comes to license/readme files, I think that would be could. So my suggestion would be to simply install all files from DocFiles into both packages. This way we don't have to worry about %n either etc. Seems pretty elegant to me in fact :) > Or else rename %i/share/doc/%n to >%i/share/doc/%n-shlibs during the move, which sounds dangerous. Would be dangerous, I agree. 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
