- cabal-devel - Haskell.org

patch applied (cabal): Add ghc.mk for the new GHC build system
by Ian Lynagh 05 Jun '09

05 Jun '09

Tue Mar 24 14:18:19 PDT 2009 Ian Lynagh <igloo(a)earth.li> * Add ghc.mk for the new GHC build system A ./doc/ghc.mk View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090324211819-3fd76-7fbeff7c…

1 0

patch applied (cabal-branches/cabal-install-0.6): Simplify version ranges before printing in error messages
by Duncan Coutts 05 Jun '09

05 Jun '09

Sun May 31 12:13:46 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Simplify version ranges before printing in error messages Part of ticket #369 M ./Distribution/Client/Dependency/TopDown.hs -8 +18 View patch online: http://darcs.haskell.org/cabal-branches/cabal-install-0.6/_darcs/patches/20…

1 0

patch applied (cabal-branches/cabal-install-0.6): Only apply preferences to base if its version is unbounded above
by Duncan Coutts 05 Jun '09

05 Jun '09

Thu Jun 4 18:04:36 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Only apply preferences to base if its version is unbounded above This is a backport to the cabal-install 0.6.x series. It relies on the VersionIntervals ADT which was added in Cabal-1.7.x, so that also had to be backported. M ./Distribution/Client/Dependency/TopDown.hs -5 +20 View patch online: http://darcs.haskell.org/cabal-branches/cabal-install-0.6/_darcs/patches/20…

1 0

patch applied (cabal-branches/cabal-install-0.6): Backport VersionIntervals ADT from Cabal-1.7
by Duncan Coutts 05 Jun '09

05 Jun '09

Thu Jun 4 17:59:17 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Backport VersionIntervals ADT from Cabal-1.7 A ./Distribution/Compat/Version.hs M ./cabal-install.cabal +1 View patch online: http://darcs.haskell.org/cabal-branches/cabal-install-0.6/_darcs/patches/20…

1 0

patch applied (cabal-branches/cabal-install-0.6): Only report preferred new versions of cabal-install are available
by Duncan Coutts 05 Jun '09

05 Jun '09

Thu Jun 4 10:57:26 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Only report preferred new versions of cabal-install are available That is, use the "preferred-versions" mechanism when deciding whether there is a new version available. This would allow us to upload a new version without everyone immediately being told to get it and try it out. M ./Distribution/Client/Update.hs -12 +21 View patch online: http://darcs.haskell.org/cabal-branches/cabal-install-0.6/_darcs/patches/20…

1 0

[Hackage] #549: The reason for an upload error is not reported
by Hackage 04 Jun '09

04 Jun '09

#549: The reason for an upload error is not reported ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ I don't have a paste to hand, but when `cabal upload` fails due to an error from the server, the error message is not displayed unless you also increase the verbosity (`-v3` worked for me). See also #338. Apparently this also affects download, not only upload. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/549> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

patch applied (cabal-install): Fix use of deprecated version constructors
by Duncan Coutts 04 Jun '09

04 Jun '09

Thu Jun 4 11:05:00 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Fix use of deprecated version constructors M ./Distribution/Client/Update.hs -2 +2 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20090604180500-adfee-…

1 0

patch applied (cabal-install): Only report preferred new versions of cabal-install are available
by Duncan Coutts 04 Jun '09

04 Jun '09

Thu Jun 4 10:57:26 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Only report preferred new versions of cabal-install are available That is, use the "preferred-versions" mechanism when deciding whether there is a new version available. This would allow us to upload a new version without everyone immediately being told to get it and try it out. M ./Distribution/Client/Update.hs -12 +21 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20090604175726-adfee-…

1 0

patch applied (cabal-install): Make cabal upload/check print out the error messages reported by the server
by Duncan Coutts 04 Jun '09

04 Jun '09

Thu Jun 4 05:48:36 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Make cabal upload/check print out the error messages reported by the server The code to do it was already there but we were checking for the mime type text/plain using just (==) when in fact the server reports text/plain; charset="ISO-8859-1" so we have to parse the field a bit better (still a bit of a hack). M ./Distribution/Client/Upload.hs -4 +6 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20090604124836-adfee-…

1 0

Re: Notice for package authors
by Duncan Coutts 04 Jun '09

04 Jun '09

On Thu, 2009-06-04 at 09:13 +0000, kahl(a)cas.mcmaster.ca wrote: > [Not replying to haskell-cafe since not subscribed.] > > Duncan wrote: > > > > There is no way for the tools to discover if you mean base 3 or 4 and > > yet most packages break when we pick the wrong one. You must specify an > > upper bound so that your package does not break when the next major > > version of the base library is released. > > > > For example, if you've tested with base 3 and 4 then use: > > > > build-depends: base >= 3 && < 5 > > Then ``build-depends'' is a misnomer because most packages will most likely > not DEPEND on the fact that the used base package has version less than 5. It depends on how much base 5 changes from 4 as to the likelihood of the package breaking. Looking back at the days of base 2, I think retrospectively we can reasonably say that all the packages that used "build-depends: base >=2" really did "DEPEND" on the fact that the used base package has version less than 3. The transition to base 3 was very disruptive, only the most trivial programs did not break. It's true that it's pessimistic and based on future unknowns. Other people have also suggested that it should not be "depends" but something else to say that it's a speculative upper bound rather than a known one based on testing. > This misnomer is one major source of my uneasiness with cabal. The upper bound bits specifically or generally using version ranges? Version ranges do only make sense when you know the versioning policy of the package you're depending on, so that you know how changes in future versions of the package will be reflected in version number changes. > I would like to propose ``tested-with'' as a better name, > and would like to see a way for users to easily test with a version > I did not have avaliable, and report that back (perhaps to hackage). Certainly speculatively trying with later versions and reporting is a useful thing. Doing it via hackage build clients and emailing authors would be nice. > Of ocurse, I can, for example, honestly only write > > tested-with: base `elem` [2.1.1, 3.0.1.0, 3.0.3.1, 4.1.0.0] > > because those are the versions I happen to have lying around, > and you probably would like to allow building with Given that you know the versions that worked and you know that the package in question is following the PVP (otherwise none of this makes sense) then you can derive the upper bounds you're interested in. > But in general there is no guarantee that a give package actually > implements that, or does hackage test for compliance with the > version convention? Right, it only makes sense if you know the versioning policy of the package. In particular we know base follows the PVP. An idea is to let packages opt-in to following a named version policy (eg the PVP). > Yet another problem is that if I write > > tested-with: > pkg1 == v1_1 || == v1_2 > ... > pkg9 == v9_1 || == v9_2 > > , I probably won't have tested all 2^9 combinations... Yes, we have to assume some kind of independence. Clearly version numbers are an approximation of precise type (and semantic) interfaces. It's not a total solution but should help significantly reduce the number of packages that needlessly break in confusing ways when end-users upgrade things. We're certainly not trying to suppress ideas or work on better, more complete solutions. In the mean time we're trying to reduce the expected pain of breakage at major transitions. Duncan

1 0