Cabal: pkg-config uses a more general version scheme

[bos]

(Imported from Trac #170, reported by @dcoutts on 2007-11-05)

From HsOpenSSL.cabal

  --PkgConfig-Depends: openssl >= 0.9.7l

  -- We really should use this instead of the configure

  -- script but Cabal 1.2.2.0 can't handle the weird version

  -- scheme of OpenSSL.

For example:

$ pkg-config --modversion openssl

0.9.8f

Currently Cabal tries to map pkg-config versions to the standard Version type which only allows for a sequence of numbers.

pkg-config uses just strings to represent package versions. It uses code lifted from rpm to compare version strings. See the compare_versions function in pkg-gconfig-0.22/pkg.c from http://pkgconfig.freedesktop.org/releases/pkg-config-0.22.tar.gz

[bos]

(Imported comment by @dcoutts on 2007-11-05)

A possibly-better reference for the rpm version string comparison code:
rpmEVRcmp

[bos]

(Imported comment by guest on 2008-01-26)

I got

$ cabal install

Resolving dependencies...

Configuring alsa-core-0.5.0.1...

cabal: parsing output of pkg-config --modversion failed

cabal: Error: some packages failed to install:

alsa-core-0.5.0.1 failed during the configure step. The exception was:

ExitFailure 1

because

$ pkg-config --modversion alsa

1.0.14a

I remember that Cabal had functions for parsing version numbers with tags, would this help here?
Newer ALSA versions do not seem to have the version tag anymore.

[bos]

(Imported comment by guest on 2011-03-05)

How about using pkg-config's --atleast-version option? Then Cabal does not need to parse the version number at all.

[bos]

(Imported comment by @dcoutts on 2011-03-05)

We do need to parse the version because people can use arbitrarily complicated version constraints, not just ">= x.y". I think we just need to do it properly and have pkg-config versions use a different type internally than Version, and use different version comparison code.

[tibbe]

Closing as there's been no activity in years.

We're cleaning up the bug tracker to make it useful again and are thus closing bugs that haven't seen any activity in a long time. Please re-open (or file a new bug) if the problem reappears.

[mietek]

This is still an issue.

With pkgconfig-depends: openssl, Cabal fails as follows:

$ cabal build
Resolving dependencies...
Configuring foo-0.0.1...
cabal: parsing output of pkg-config --modversion failed

This is due to the openssl version number format:

$ pkg-config --modversion openssl
0.9.8y

[BardurArantsson]

@mietek Do you have the ability and/or inclination to help with fixing this issue? If you're keen the Cabal developers are going to be very grateful for any manpower you can offer. Given how long this has gone unaddressed, I fear it'll go on being unresolved otherwise.

I propose this be closed -- if @mietek wants he can reopen. (But please only do so if you want to help address it or know somebody who can.)

[hvr]

@23Skidoo
For the record, pkg-config seems to use the same version comparison that rpm uses (or used at some point), see http://cgit.freedesktop.org/pkg-config/tree/rpmvercmp.c

[nomeata]

I have been observing that when building bindings-sane on Debian. @mtolly, are you still planning to fix this?

[mtolly]

My apologies, this has fallen off my radar for a while now. In #2730 you can see that it got a bit more complicated, and as far as I could tell, clear decisions weren't really reached regarding where the extra tags should be allowed, and whether they should be ignored or actually used for comparison (and, what comparison function should be used). In addition my own reason for needing the fix mostly went away. So, anyone else is certainly free to pick this back up.

[kenta2]

Yet one more package that this bug affects is hlibBladeRF-0.1.0.6 which depends on libbladeRF. Ubuntu 14.04 provides
$ pkg-config --modversion libbladeRF
0.10.0-0.9.0.15.8ba2499

This one almost parses correctly as a tag; the only issue is that simpleParse in Cabal/Distribution/Text.hs assumes tags are Char.isAlphaNum, but the period is not alphanumeric.

[ezyang]

Perhaps, as a stopgap, we should just truncate the version string at the point where it stops looking like a normal version? This should be easy to implement, should be a very small change, and will get more packages compiling than before.

[idontgetoutmuch]

This still seems to be a problem

[nix-shell:~/hmatrix/packages/gsl]$ cabal build
Resolving dependencies...
Configuring hmatrix-gsl-0.18.2.0...
cabal: parsing output of pkg-config --modversion failed

[nix-shell:~/hmatrix/packages/gsl]$ cabal --version
cabal-install version 2.0.0.1
compiled using version 2.0.1.1 of the Cabal library 

[nix-shell:~/hmatrix/packages/gsl]$ pkg-config --version
0.29.2

[23Skidoo]

5098 is related.

[phadej]

@idontgetoutmuch , what does pkg-config --modversion gsl says on your machine?

[amigalemming]

In Debian Buster the package libopenblas-dev has version 0.3.5+ds and Cabal fails to parse that:

~~~~
$ pkg-config --modversion lapack
0.3.5+ds
$ pkg-config --modversion blas
0.3.5+ds
$ sudo update-alternatives --config libblas.so-x86_64-linux-gnu
There are 2 choices for the alternative libblas.so-x86_64-linux-gnu (providing /usr/lib/x86_64-linux-gnu/libblas.so).

Selection Path Priority Status

• 0 /usr/lib/x86_64-linux-gnu/openblas/libblas.so 100 auto mode
  1 /usr/lib/x86_64-linux-gnu/blas/libblas.so 10 manual mode
  2 /usr/lib/x86_64-linux-gnu/openblas/libblas.so 100 manual mode

Press to keep the current choice[*], or type selection number:
~~~~

[idontgetoutmuch]

@idontgetoutmuch , what does pkg-config --modversion gsl says on your machine?

pkg-config --modversion gsl
2.5

But this is very out of date.