[Hackage] #753: cabal executable chooses different versions of libraries than cabal library

#753: cabal executable chooses different versions of libraries than cabal library ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Hi, cabal-install version 0.8.2 using version 1.8.0.2 of the Cabal library This bug was originally reported by a Debian user. the `cabal' executable, when run on the attached sample library, chooses base 3.0.3.2: $ cabal -v configure [...] Configuring foobar-0.0... Dependency base ==3.0.3.2: using base-3.0.3.2 [...] whereas, the library (via Setup.hs) correctly gets base 4.2.0.0, probably due to ghc's hiding of the earlier version $ runhaskell Setup.hs -v configure Configuring foobar-0.0... Dependency base -any: using base-4.2.0.0 [...] cabal-install should probably perform the same hiding that ghc does. Cheers, Iain -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/753 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects

#753: cabal configure choosing base 3 is confusing ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Comment(by duncan): This behaviour is due to backward compatibility hacks in cabal-install. When you run `cabal configure` it uses its constraint solver and various preferences to decide what dependencies to pick. When you run `rughc Setup configure` it just blindly picks the latest version of everything (whether or not the set of versions it picks have consistent dependencies). One of the things that `cabal configure` does is to make lots of old packages work that never specified what version of base they want. They were written when base 3 was around and so were not tested with base 4, but they specified: {{{ build-depends: base >= 3 }}} Normally we would interpret this as allowing any version greater than 3, but the problem when base 4 came out was that all these packages broke, because cabal would pick base 4. The hack was to reinterpret what an upwards open constraint means on base. If the range is open we apply a preference for base 3. If it is closed we treat it normally. So if you write: {{{ build-depends: base >= 3 && < 5 }}} then cabal will pick base 4, if it's available. The problem now is new packages where people just list: {{{ build-depends: base }}} They expect the latest version to be picked. I think what we need to do is to add a warning that they should specify an upper bound and that the older version is being defaulted to. Note that it is not practical to make `cabal configure` and `runghc Setup configure` do exactly the same thing, because that either means making `cabal configure` dumb, or it means moving the constraint solver into the Cabal library. I think the right solution to this inconsistency is to encourage users to use the cabal program as the main UI, and stop using `runghc Setup`, leaving that interface just as a machine interface for things like distro packaging scripts. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/753#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects

#753: cabal configure choosing base 3 is confusing ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Comment(by adept): Perhaps "runghc Setup" could print a warning, when run interactively? -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/753#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects

#753: cabal configure choosing base 3 is confusing ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Comment(by duncan): Replying to [comment:2 adept]:
Perhaps "runghc Setup" could print a warning, when run interactively?
It's not trivial to detect accurately, but perhaps we can use the lack of a `--prefix` flag as an indication that a human is using it rather than a script, since any packaging/distro tool would be specifying where to install. Hmm, though perhaps GUI tools would not, they might want to use whatever the default is. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/753#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects

#753: cabal configure choosing base 3 is confusing ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Comment(by elga): * [http://www.releve-identite-operateur.fr/rio-simyo.html simyo] -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/753#comment:4 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects

#753: cabal configure choosing base 3 is confusing ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: cabal-install-0.14 Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Changes (by kosmikus): * milestone: => cabal-install-0.14 Comment: I'm tempted to close this as "wontfix". The base-3/4 issue is not really relevant anymore. Also, the new modular solver is better at treating preferences just as "preferences", not hard rules. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/753#comment:4 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects

#753: cabal configure choosing base 3 is confusing ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: closed Priority: normal | Milestone: cabal-install-0.14 Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Resolution: wontfix Keywords: | Difficulty: unknown Ghcversion: | Platform: ---------------------------------+------------------------------------------ Changes (by kosmikus): * status: new => closed * resolution: => wontfix Comment: Closing this for now. It's still true that there are some situations where calling a local configure will lead to different results than invoking cabal-install, but I think that's unavoidable. If there's still a real problem using a current example, I'd like to see it. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/753#comment:5 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
participants (1)
-
Hackage