At 17:11 Uhr -0500 02.02.2002, David R. Morrison wrote: >Hi again Max. > >I was looking more closely at a shared library example in Debian, and it >appears that they use a similar trick to what you've just done with zlib: >they divide the files between the packages like this: > >Package foo contains: > /sw/lib/foo.N.x.y.dylib > /sw/lib/foo.N.dylib -> /sw/lib/foo.N.x.y.dylib > >Package foo-devel contains: > /sw/include/foo.h > /sw/lib/foo.a > /sw/lib/foo.dylib -> /sw/lib/foo.N.dylib > >The idea is, whenever you are compiling a new package you have the >appropriate foo-devel installed. This *should* mean that the library >which the new package is linked against is recorded as /sw/lib/foo.N.dylib >If you are careful, no package should ever be looking for a dynamically >linked library which is recorded as /sw/lib/foo.dylib Also, if you choose >to include a static library you will only need it around when someone >is compiling. > >This system avoids the conflicts we were observing last night.
Indeed! I have some thoughts on this, too: Debian uses "foo-devel" and "foo" as package names. This makes sense from a logic point of view. However, I think maybe for us it would be better to go with "foo" (instead of foo-devel) and "foo-shlib" (instead of foo). This would give us full backward compatibility. That is, existing packages wouldn't have to be changed, even if we convert their dependencies. And new packages can split their "Depends: foo" into "Depends: foo-shlib" and "Builddepends: foo". Also, it might be possible to semi-automate the splitting of packages, all via single shlibs field. e.g. something like: Shlibs: << libfoo REV libfoomm REV << If Fink encounters this, it would do multiple things: * split the package internally into two, foo and foo-shlib * upon build time, create both .debs, where foo-shlib would only contains the shared libraries mentioned in the Shlibs field * both would share the version/revision information * the "foo" package would correctly depend on "foo-shlib (==VERSION)", i.e. it would require the exact matchin version of foo-shlib One concern is the depends/conflicts field - so maybe we add ShlibsDepend and ShlibsConflicts. However, note that the dependencies for foo-shlibs basically should be fully determined by the shared libs the files in foo-shlibs depends on, which in turn would be automatically computed. In other words, there would be almost no need for ShlibsDepends and ShlibsConflicts except in the rare odd case. There is one flaw: the filenames for some dylibs are not exactly standardized, so we may have to add a way to specify the exact list of filenames for foo-shlib. I hope that made some sense. Awaiting comments! >However, I am a bit worried about it since I don't understand what just >happened with the new zlib (see my other message). See my other message :) 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
