Hi, currently I've got a problem installing from hackage. using: GHC (package manager) version 6.10.0.20081019 cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library I get: Building network-2.2.0.0... Network/URI.hs:128:7: Could not find module `Data.Generics': it is a member of package base-3.0.3.0, which is hidden even with: cabal install network --constrain="base<4" (A similar problem happened with Shellac.) How is the smart selection between base-3 and base-4 going to work? Eventually, I want to install hxt-filter and Shellac-compatline. (The interface in editline changed for Shellac-editline.) Cheers Christian
On Mon, 2008-10-20 at 16:28 +0200, Christian Maeder wrote:
Hi,
currently I've got a problem installing from hackage. using: GHC (package manager) version 6.10.0.20081019 cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library
I get:
Building network-2.2.0.0...
Network/URI.hs:128:7: Could not find module `Data.Generics': it is a member of package base-3.0.3.0, which is hidden
The basic problem here is that the version number of the network package has not been bumped. You probably installed from a ghc bindist that has network-2.2.0.0 already, however it's not the same as network-2.2.0.0 from hackage. The pre-installed one is built against base-4, so when cabal-install tries to rebuild it then it tries to build it against base 4 which does not work because the one on hackage has not been updated. Normally cabal-install would use base-3 but in this case it's picking 4 because the version that is already installed used 4 so the assumption is that since the same version is already installed then it does indeed work with base 4. Of course that's not true here because the package has changed without the version being bumped. Indeed the only reason it's trying to rebuild it at all is because the installed version has different deps from the available version, again due to the fact that it changed without changing version number. So the solution is for the updated network package to have its version bumped and for it to be released. Duncan
The basic problem here is that the version number of the network package has not been bumped. .. .. Of course that's not true here because the package has changed without the version being bumped. .. Indeed the only reason it's trying to rebuild it at all is because the installed version has different deps from the available version, again due to the fact that it changed without changing version number.
So the solution is for the updated network package to have its version bumped and for it to be released.
For ghc at least, couldn't cabal grep the hashes from the output of find dist/ -name '*.hi' | xargs ghc --show-iface and associate the collection of hashes for the exposed-modules and cross-package imports with the version number, keeping a history of these associations? cabal tag-current would try to add the current version number with the current hashes, complaining if the number already exists with different hashes cabal sdist (and other distribution channels) would check that the current version number is in the history with the current hashes, and complain otherwise Distributing packages without version number checks could result in in "unverified" packages, so users would know that the dependencies and version number haven't been checked (successful checks could create a package signature based on .cabal+.history, or on the whole package contents). Or are Ghc's new hashes non-portable/too specific? Claus
On Mon, 2008-10-20 at 20:20 +0100, Claus Reinke wrote:
The basic problem here is that the version number of the network package has not been bumped. .. .. Of course that's not true here because the package has changed without the version being bumped. .. Indeed the only reason it's trying to rebuild it at all is because the installed version has different deps from the available version, again due to the fact that it changed without changing version number.
So the solution is for the updated network package to have its version bumped and for it to be released.
For ghc at least, couldn't cabal grep the hashes from the output of
find dist/ -name '*.hi' | xargs ghc --show-iface
and associate the collection of hashes for the exposed-modules and cross-package imports with the version number, keeping a history of these associations?
Unfortunately the interface can change depending on the way the package is built, in particular the versions of the dependencies it is built with. This is because packages are really functors, parameterised by their dependencies. For this reason we can only associate hashes with built/installed packages, not with source packages on hackage. However for installed packages we certainly should track the package ABI hash. This will help in verifying the dependencies of built packages. It's also the starting point for a nix-style persistent built-package store. Duncan
Claus Reinke wrote:
The basic problem here is that the version number of the network package has not been bumped. .. .. Of course that's not true here because the package has changed without the version being bumped. .. Indeed the only reason it's trying to rebuild it at all is because the installed version has different deps from the available version, again due to the fact that it changed without changing version number.
So the solution is for the updated network package to have its version bumped and for it to be released.
For ghc at least, couldn't cabal grep the hashes from the output of
find dist/ -name '*.hi' | xargs ghc --show-iface
and associate the collection of hashes for the exposed-modules and cross-package imports with the version number, keeping a history of these associations?
cabal tag-current would try to add the current version number with the current hashes, complaining if the number already exists with different hashes
cabal sdist (and other distribution channels) would check that the current version number is in the history with the current hashes, and complain otherwise
Distributing packages without version number checks could result in in "unverified" packages, so users would know that the dependencies and version number haven't been checked (successful checks could create a package signature based on .cabal+.history, or on the whole package contents). Or are Ghc's new hashes non-portable/too specific?
GHC's hashes aren't suitable for this (yet). We do not hash the API, but rather the ABI, and the ABI is often not stable - re-compiling can give you a different ABI, as internal names change and things move around in unpredictable ways. However I do think we should have a way to get a dump of the API. We've talked in the past about having some kind of API tool that would compare APIs and show you the differences (built on the GHC API of course). This would make a nice little project for someone... Cheers, Simon
Duncan Coutts wrote:
The basic problem here is that the version number of the network package has not been bumped.
see below
You probably installed from a ghc bindist that has network-2.2.0.0 already,
Yes, you're right, and I didn't notice that, because I relied on cabal install.
however it's not the same as network-2.2.0.0 from hackage. The pre-installed one is built against base-4, so when cabal-install tries to rebuild it then it tries to build it against base 4 which does not work because the one on hackage has not been updated.
So network-2.2.0.0 should be linked against base-3 within the binary dist of ghc-6.10 (or not shipped with ghc-6.10 at all. In fact it worked after I've unregistered my global network-2.2.0.0, first! (but I didn't get much further, see below)
Normally cabal-install would use base-3 but in this case it's picking 4 because the version that is already installed used 4 so the assumption is that since the same version is already installed then it does indeed work with base 4. Of course that's not true here because the package has changed without the version being bumped.
Or cabal-install should be smarter (or less smart).
Indeed the only reason it's trying to rebuild it at all is because the installed version has different deps from the available version, again due to the fact that it changed without changing version number.
So the solution is for the updated network package to have its version bumped and for it to be released.
So why is the version of network not bumped, yet? The maintainer is libraries@haskell.org. Would it interfere with ghc-6.8? Cheers and thanks for your explanation Christian P.S. for hxt and Shellac-editline the sources need to be changed for ghc-6.10: [ 49 of 112] Compiling Text.XML.HXT.RelaxNG.DataTypeLibUtils ( src/Text/XML/HXT/RelaxNG/DataTypeLibUtils.hs, dist/build/Text/XML/HXT/RelaxNG/DataTypeLibUtils.o ) src/Text/XML/HXT/RelaxNG/DataTypeLibUtils.hs:67:7: `>>>' is not a (visible) method of class `Arrow' cabal: Error: some packages failed to install: hxt-8.1.0 failed during the building phase. The exception was: exit: ExitFailure 1 Building Shellac-editline-0.9... [1 of 1] Compiling System.Console.Shell.Backend.Editline ( src/System/Console/Shell/Backend/Editline.hs, dist/build/System/Console/Shell/Backend/Editline.o ) src/System/Console/Shell/Backend/Editline.hs:48:45: Couldn't match expected type `()' against inferred type `Bool' Expected type: IO () Inferred type: IO Bool In the expression: EL.readHistory In the `readHistory' field of a record cabal: Error: some packages failed to install: Shellac-editline-0.9 failed during the building phase. The exception was: exit: ExitFailure 1
On Tue, 2008-10-21 at 10:51 +0200, Christian Maeder wrote:
So network-2.2.0.0 should be linked against base-3 within the binary dist of ghc-6.10 (or not shipped with ghc-6.10 at all.
In fact it worked after I've unregistered my global network-2.2.0.0, first! (but I didn't get much further, see below)
network-2.2.0.1 is now on hackage which should resolve the issue.
Normally cabal-install would use base-3 but in this case it's picking 4 because the version that is already installed used 4 so the assumption is that since the same version is already installed then it does indeed work with base 4. Of course that's not true here because the package has changed without the version being bumped.
Or cabal-install should be smarter (or less smart).
Unfortunately it cannot be less smart or it'd try rebuilding haskell98 against base 3.
So why is the version of network not bumped, yet? The maintainer is libraries@haskell.org. Would it interfere with ghc-6.8?
Done, and it works with (at least) ghc-6.6.1, 6.8.2 and 6.10.0.recent. Duncan
participants (4)
-
Christian Maeder -
Claus Reinke -
Duncan Coutts -
Simon Marlow