Take into account installed pkg-config versions when resolving dependencies #3016
Comments
|
This is #335! Some implementation guidance is in that ticket. |
garetxe
pushed a commit
to haskell-gi/haskell-gi
that referenced
this issue
Jan 1, 2016
Due to a shortcoming in cabal ( haskell/cabal#3016 ) we cannot rely on it to do package version resolution properly for Haskell packages binding to external libraries, since it does not take installed versions of system packages (available via pkg-config) into account: it simply tries to install the latest version from cabal unconditionally, which will fail in most systems due to older versions of the libraries being present (older than the latest version present in hackage, which may be very recent). To work around this, we instead do tight binding of the haskell package version, but keep the pkgconfig-depends field loose. What this means is that one should depend on the lowest version of the API that is supported, with an _equality_ constraint in the cabal file. For example, using build-depends: gi-gtk == 0.3.16.* will work with installed gtk versions 3.16.* and up (3.18, 3.20, ...), but build-depends: gi-gtk >= 0.3.16 will give problems due to the shortcoming in cabal mentioned above.
garetxe
pushed a commit
to garetxe/cabal
that referenced
this issue
Jan 3, 2016
When solving, we now discard plans that would involve packages with a pkgconfig-depends constraint which is not satisfiable with the current set of installed packages (as listed by pkg-config --list-all). This fixes haskell#3016 .
garetxe
pushed a commit
to garetxe/cabal
that referenced
this issue
Jan 3, 2016
When solving, we now discard plans that would involve packages with a pkgconfig-depends constraint which is not satisfiable with the current set of installed packages (as listed by pkg-config --list-all). This fixes haskell#3016 .
garetxe
pushed a commit
to garetxe/cabal
that referenced
this issue
Jan 4, 2016
When solving, we now discard plans that would involve packages with a pkgconfig-depends constraint which is not satisfiable with the current set of installed packages (as listed by pkg-config --list-all). This fixes haskell#3016. It is possible (in principle, although it should be basically impossible in practice) that "pkg-config --modversion pkg1 pkg2... pkgN" fails to execute for various reasons, in particular because N is too large, so the command line becomes too long for the operating system limits. If this happens, revert to the previous behavior of accepting any install plan, regardless of any pkgconfig-depends constraints.
garetxe
pushed a commit
to garetxe/cabal
that referenced
this issue
Jan 9, 2016
When solving, we now discard plans that would involve packages with a pkgconfig-depends constraint which is not satisfiable with the current set of installed packages (as listed by pkg-config --list-all). This fixes haskell#3016. It is possible (in principle, although it should be basically impossible in practice) that "pkg-config --modversion pkg1 pkg2... pkgN" fails to execute for various reasons, in particular because N is too large, so the command line becomes too long for the operating system limits. If this happens, revert to the previous behavior of accepting any install plan, regardless of any pkgconfig-depends constraints.
garetxe
pushed a commit
to garetxe/cabal
that referenced
this issue
Jan 9, 2016
When solving, we now discard plans that would involve packages with a pkgconfig-depends constraint which is not satisfiable with the current set of installed packages (as listed by pkg-config --list-all). This fixes haskell#3016. It is possible (in principle, although it should be basically impossible in practice) that "pkg-config --modversion pkg1 pkg2... pkgN" fails to execute for various reasons, in particular because N is too large, so the command line becomes too long for the operating system limits. If this happens, revert to the previous behavior of accepting any install plan, regardless of any pkgconfig-depends constraints.
garetxe
pushed a commit
to garetxe/cabal
that referenced
this issue
Jan 9, 2016
When solving, we now discard plans that would involve packages with a pkgconfig-depends constraint which is not satisfiable with the current set of installed packages (as listed by pkg-config --list-all). This fixes haskell#3016. It is possible (in principle, although it should be basically impossible in practice) that "pkg-config --modversion pkg1 pkg2... pkgN" fails to execute for various reasons, in particular because N is too large, so the command line becomes too long for the operating system limits. If this happens, revert to the previous behavior of accepting any install plan, regardless of any pkgconfig-depends constraints.
garetxe
pushed a commit
to garetxe/cabal
that referenced
this issue
Jan 9, 2016
When solving, we now discard plans that would involve packages with a pkgconfig-depends constraint which is not satisfiable with the current set of installed packages (as listed by pkg-config --list-all). This fixes haskell#3016. It is possible (in principle, although it should be basically impossible in practice) that "pkg-config --modversion pkg1 pkg2... pkgN" fails to execute for various reasons, in particular because N is too large, so the command line becomes too long for the operating system limits. If this happens, revert to the previous behavior of accepting any install plan, regardless of any pkgconfig-depends constraints.
garetxe
pushed a commit
to garetxe/cabal
that referenced
this issue
Jan 9, 2016
When solving, we now discard plans that would involve packages with a pkgconfig-depends constraint which is not satisfiable with the current set of installed packages (as listed by pkg-config --list-all). This fixes haskell#3016. It is possible (in principle, although it should be basically impossible in practice) that "pkg-config --modversion pkg1 pkg2... pkgN" fails to execute for various reasons, in particular because N is too large, so the command line becomes too long for the operating system limits. If this happens, revert to the previous behavior of accepting any install plan, regardless of any pkgconfig-depends constraints.
garetxe
pushed a commit
to garetxe/cabal
that referenced
this issue
Mar 5, 2016
When solving, we now discard plans that would involve packages with a pkgconfig-depends constraint which is not satisfiable with the current set of installed packages (as listed by pkg-config --list-all). This fixes haskell#3016. It is possible (in principle, although it should be basically impossible in practice) that "pkg-config --modversion pkg1 pkg2... pkgN" fails to execute for various reasons, in particular because N is too large, so the command line becomes too long for the operating system limits. If this happens, revert to the previous behavior of accepting any install plan, regardless of any pkgconfig-depends constraints.
garetxe
pushed a commit
to garetxe/cabal
that referenced
this issue
Mar 5, 2016
When solving, we now discard plans that would involve packages with a pkgconfig-depends constraint which is not satisfiable with the current set of installed packages (as listed by pkg-config --list-all). This fixes haskell#3016. It is possible (in principle, although it should be basically impossible in practice) that "pkg-config --modversion pkg1 pkg2... pkgN" fails to execute for various reasons, in particular because N is too large, so the command line becomes too long for the operating system limits. If this happens, revert to the previous behavior of accepting any install plan, regardless of any pkgconfig-depends constraints.
garetxe
pushed a commit
to garetxe/cabal
that referenced
this issue
Mar 5, 2016
When solving, we now discard plans that would involve packages with a pkgconfig-depends constraint which is not satisfiable with the current set of installed packages (as listed by pkg-config --list-all). This fixes haskell#3016. It is possible (in principle, although it should be basically impossible in practice) that "pkg-config --modversion pkg1 pkg2... pkgN" fails to execute for various reasons, in particular because N is too large, so the command line becomes too long for the operating system limits. If this happens, revert to the previous behavior of accepting any install plan, regardless of any pkgconfig-depends constraints.
garetxe
pushed a commit
to garetxe/cabal
that referenced
this issue
Mar 5, 2016
When solving, we now discard plans that would involve packages with a pkgconfig-depends constraint which is not satisfiable with the current set of installed packages (as listed by pkg-config --list-all). This fixes haskell#3016. It is possible (in principle, although it should be basically impossible in practice) that "pkg-config --modversion pkg1 pkg2... pkgN" fails to execute for various reasons, in particular because N is too large, so the command line becomes too long for the operating system limits. If this happens, revert to the previous behavior of accepting any install plan, regardless of any pkgconfig-depends constraints.
23Skidoo
pushed a commit
that referenced
this issue
Apr 23, 2016
When solving, we now discard plans that would involve packages with a pkgconfig-depends constraint which is not satisfiable with the current set of installed packages (as listed by pkg-config --list-all). This fixes #3016. It is possible (in principle, although it should be basically impossible in practice) that "pkg-config --modversion pkg1 pkg2... pkgN" fails to execute for various reasons, in particular because N is too large, so the command line becomes too long for the operating system limits. If this happens, revert to the previous behavior of accepting any install plan, regardless of any pkgconfig-depends constraints. (cherry picked from commit c72aa8d) + Monitor the pkg-config db for changes We use the pkg-config db as an input for the solver, so we ought to monitor it for changes. The pkg-config tool makes this possible, if not totally trivial. (cherry picked from commit f968b41)
23Skidoo
pushed a commit
to 23Skidoo/cabal
that referenced
this issue
Apr 23, 2016
When solving, we now discard plans that would involve packages with a pkgconfig-depends constraint which is not satisfiable with the current set of installed packages (as listed by pkg-config --list-all). This fixes haskell#3016. It is possible (in principle, although it should be basically impossible in practice) that "pkg-config --modversion pkg1 pkg2... pkgN" fails to execute for various reasons, in particular because N is too large, so the command line becomes too long for the operating system limits. If this happens, revert to the previous behavior of accepting any install plan, regardless of any pkgconfig-depends constraints. (cherry picked from commit c72aa8d) + Monitor the pkg-config db for changes We use the pkg-config db as an input for the solver, so we ought to monitor it for changes. The pkg-config tool makes this possible, if not totally trivial. (cherry picked from commit f968b41)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When constructing the installation plan, it seems like pkg-config does not take into account the versions of the installed system packages, and it always chooses the latest available version from hackage. This makes distributing bindings in hackage for the latest version of a given library fairly difficult, as far as I can tell. (Maybe there is a way? I would be happy to learn if so.)
An example may make this clearer. Consider the
gi-glibbindings forGLib:http://hackage.haskell.org/package/gi-glib
The latest version of the
gi-glibpackage, 0.2.46.10, has apkgconfig-depends; glib-2.0 >= 2.46line in the cabal file. This version ofGLibis fairly recent, and is not included in Fedora 22 for example. The version there is2.44, which would work with version0.2.44.10ofgi-glib.So when I try to do
cabal install gi-glibin Fedora 22 the install fails withsince cabal always tries to install the latest version in hackage,
gi-glib-0.2.46.10, which needs a too newGLib.What would be ideal is if in this situation cabal chose the latest version of
gi-glibcompatible with theGLibversion in the system, as specified in thepkgconfig-dependsfield in the cabal file.Would this be possible?
Otherwise I see (as maintainer of
gi-glib) no useful way of having bindings to the latest released version ofGLibin hackage (I would have to wait until most users have upgraded their systems, which may take a few years...). Is there perhaps a different way of achieving this?The text was updated successfully, but these errors were encountered: