need a way to specify the foreign libraries a package depends on

[ross@…]

Package descriptions allow one to specify which Haskell libraries a package depends on, but foreign ones. Designing something that can be used with native package managers is complicated because many of them alter the upstream library names in unpredictable ways.

[duncan]

Note that we already have some partial information, like extra-libraries:, includes:, pkgconfig-depends: and frameworks:.

[dons]

In addition, we can see the lack of checking for the existence of C libs breaking test builds on hackage, and breaking cabal-install downloads.

pcre-light is a good example: no way to test pcre.h is available, without resorting to autoconf.

One solution here might be to reuse/duplicate autoconf functionality to check if extra-libraries are available?

[duncan]

See also #177, suggestion that we can at least check at configure time if all required C libs and header files can be found. Of course that does not relate them back to what packages those C libs belong to, but it'd give better error messages.

[guest]

#177 is actually about checking for directories.

See also:

• #15 and #159 - implement dependency analysis
• #262 - check for required foreign libraries

[duncan]

Module/file dependency analysis is not relevant (#15 and #159). That's a different kind of dependency.

#177 and #262 are closely related though.

[duncan]

Do we really need this? I'm not sure we do.

We can already specify that we need C libs and headers (and frameworks and pkg-config packages). Do we also need to be able to specify the native packages that provide those C libs and headers?

When we make native packages from cabal packages we can derive which other native packages provide the C libs and headers. For example if we have extra-libraries: z then the cabal->native tool just asks the package manager which package provides the file /usr/lib/libz.so. Obviously this is system-specific.

[ross@…]

Replying to duncan:

Do we really need this? I'm not sure we do. We can already specify that we need C libs and headers (and frameworks and pkg-config packages). Do we also need to be able to specify the native packages that provide those C libs and headers?

OK, I'll buy that.

[lemming]

We have support for different compilers, why not also having support for different package systems? We could either sort the dependencies with respect to distributions:

Debian-Depends: zlib-devel, alsa-devel
Fedore-Depends: zlib-devel, alsa-devel

or with respect to needed files:

File-Depends: zlib.h - zlib-devel.rpm >= 0.4, zlib-devel.deb >= 0.4
File-Depends: asound.h - alsa-devel.rpm >= 2.0, alsa-devel.deb >= 2.0

[duncan]

I think the native package conversion tools should be doing this reverse dependency lookup, matching headers, C libs or build tools that packages need to native packages. It does not scale to ask package authors to know what native package name and version is needed on each different system (in particular they would have no way to test it).

[duncan]

Closing again. Based on the previous discussion I'm satisfied that we do not need this.