On 14 July 2005 14:45, Simon Marlow wrote:
When I installed the new Cabal globally (onto GHC 6.4), the old one was hidden automatically, so the suggestion for unregistering the old one in the README is unecessary.
I take it back. If you don't unregister the old one, then "-package Cabal" results in an error from GHC ("Cabal matches multiple packages"), and building GHC fails. In hindsight this was a bad choice, I'm going to change it so that -package P picks the latest version of P if a particular version isn't specified. However, upgrading Cabal might still cause problems for GHC, because our build system relies on knowing what version of GHC you're building with to know what version of Cabal you're using. This is not really Cabal's problem.
So to summarise:
- to install globally / with root access: should "just work"
- to install just for me: copy+hide Cabal-1.0, then install the new one with --user.
I should really do something about this for 6.4.1. Everything seems a bit adhoc, though. Perhaps: in the absence of any package flags to the contrary, GHC could default to hiding all but the newest version of packages which have more than one version exposed?
I've made the following changes for 6.4.1: - -package P picks the latest version of P, instead of complaining if P is ambiguous. - -hide-package P hides all versions of P, instead of complaining if P is ambiguous. - -package P hides all other versions of P (this was advertised in the documentation, but wasn't actually implemented in 6.4) - if multiple packages with the same name are still exposed after the flags have been processed, then all except the latest version are hidden. This is aimed at reducing the error cases and making it DTRT for most people. Comments? Cheers, Simon
"Simon Marlow"
On 14 July 2005 14:45, Simon Marlow wrote:
When I installed the new Cabal globally (onto GHC 6.4), the old one was hidden automatically, so the suggestion for unregistering the old one in the README is unecessary.
I take it back. If you don't unregister the old one, then "-package Cabal" results in an error from GHC ("Cabal matches multiple packages"), and building GHC fails. In hindsight this was a bad choice, I'm going to change it so that -package P picks the latest version of P if a particular version isn't specified.
Sounds good.
However, upgrading Cabal might still cause problems for GHC, because our build system relies on knowing what version of GHC you're building with to know what version of Cabal you're using. This is not really Cabal's problem.
Hmm. I guess this can't be determined at GHC's build time. What is this info used for? (snip)
I've made the following changes for 6.4.1:
- -package P picks the latest version of P, instead of complaining if P is ambiguous.
- -hide-package P hides all versions of P, instead of complaining if P is ambiguous.
- -package P hides all other versions of P (this was advertised in the documentation, but wasn't actually implemented in 6.4)
- if multiple packages with the same name are still exposed after the flags have been processed, then all except the latest version are hidden.
We basically have three dimensions of a single package to consider: - hidden vs. exposed - user vs. global vs. -package-conf - versions I propose that -package-conf packages have priority over user packages which have priority over global packages (are all three considered at the same time?) What do we do if multiple "dimensions" of the same package are exposed? Right now, ghc just quits, right? I propose: Pick the Exposed -package-conf package with greatest version number if none, the exposed user package with greatest version number if none, the exposed system package with the greatest version number. This is the same whether they use the -package flag for this package or not, since it's already exposed. If they use the -package-related flags, I propose: - -package P picks the latest version of P, (with -package-conf vs. user vs. global preferences as above) , instead of complaining if P is ambiguous. - -hide-package P hides all versions of P (including -package-conf, user and global packages), instead of complaining if P is ambiguous. - -package P hides all other versions of P (including -package-conf, user and global packages) (this was advertised in the documentation, but wasn't actually implemented in 6.4) - if multiple packages with the same name are still exposed after the flags have been processed, then all except the latest version are hidden, competing as above. peace, isaac
participants (2)
-
Isaac Jones -
Simon Marlow