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

[bos]

(Imported from Trac #216, reported by ross on 2008-01-26)

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.

[bos]

(Imported comment by @dcoutts on 2008-01-26)

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

[bos]

(Imported comment by @dons on 2008-01-26)

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?

[bos]

(Imported comment by @dcoutts on 2008-02-12)

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.

[bos]

(Imported comment by guest on 2008-02-12)

#177 is actually about checking for directories.

See also:

• fix unix dependency for ghc 6.2 #15 and sdist puts Happy-generated .hs files in the wrong place #159 - implement dependency analysis
• Not having an up-to-date package list causes indexing out of bounds error #262 - check for required foreign libraries

[bos]

(Imported comment by @dcoutts on 2008-03-25)

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

#177 and #262 are closely related though.

[bos]

(Imported comment by @dcoutts on 2008-03-25)

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.

[bos]

(Imported comment by ross on 2008-06-19)

Replying to @dcoutts:

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.

[bos]

(Imported comment by lemming on 2008-06-19)

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

[bos]

(Imported comment by @dcoutts on 2008-07-08)

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).

[bos]

(Imported comment by @dcoutts on 2008-08-15)

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