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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
