Dear Fink developers, As some of you know, the "pkgconfig" system is being used extensively with GNOME2 packages and possibly with other systems as well. The pkgconfig system aims to solve the problem of multiple versions of a shared library by (1) carefully giving different names to different major versions of the library, (2) storing header files in unique subdirectories, (3) keeping track of appropriate CFLAGS and LDFLAGS to pass to the compiler and linker, and (4) keeping track of dependencies on other pkgconfig-using packages.
Fink's shared library system, with -shlibs and -dev splitoffs, aims to solve the same problem. These two systems are not interfacing as well as they might. In particular, the pkgconfig files are being stored in the -dev splitoffs where they belong, but to function properly they should perhaps "Depend" on other -dev splitoffs. However, adding those dependencies would violate Fink policy and in fact would defeat the goal of the Fink policy regarding -dev splitoffs. I have a two-part policy to propose. The first part is a short-term solution to the problem, and should be non-controversial. I intend to start implementing it right away. The second part is a proposed longer-term solution to the problem, which may be controversial. I encourage discussion about it. SHORT TERM SOLUTION: Although we should not allow a -dev splitoff to Depend on another -dev splitoff, we can use the "Recommends" field to specify the other -dev splitoffs which are relevant. This will be useful for package maintainers, who will simply need to consult the "Recommends" field to find out which things they need to add to the "BuildDepends" line in their own packages. LONG TERM SOLUTION: It seems to me that in the long term, for packages using pkgconfig we can allow both the headers and the root dylib symlink to go into the -shlibs package, i.e., we can merge the -dev and -shlibs packages in such a case. This is because the pkgconfig system is explicitly designed to allow multiple versions to be installed simultaneously. The reason that the "long term solution" can't be implemented immediately is because of our existing -dev packages. We could create new versions of packages in which foo-shlibs "provides" foo-dev, but that won't work for any package that has a versioned depedency on foo-dev. Thus, the process of converting from the short-term to the long-term solution may be a rather long one (assuming that folks like the long-term solution). Feedback appreciated. -- Dave ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
