#435: ban upwardly open version ranges in dependencies on base
+---
Reporter: duncan |Owner:
Type: enhancement| Status: new
Priority: normal |Milestone:
Sat Mar 21 08:46:23 PDT 2009 Duncan Coutts dun...@haskell.org
* Improve the parse error message for package name/deps
Make it clear that it's the specification of the package name that
is at fault rather than the package to which the name refers.
M ./Distribution/Client/Setup.hs -1 +3
#435: ban upwardly open version ranges in dependencies on base
+---
Reporter: duncan |Owner:
Type: enhancement| Status: new
Priority: normal |Milestone:
#435: ban upwardly open version ranges in dependencies on base
+---
Reporter: duncan |Owner:
Type: enhancement| Status: new
Priority: normal |Milestone:
Hi Ross,
I'd like to get Hackage using the new check for base being bounded
above. I think it'll make a big difference when it comes to future
ghc/base upgrades. The last one was papered over by cabal-install
defaulting to base 3 when the package author did not specify otherwise.
That will not
#435: ban upwardly open version ranges in dependencies on base
+---
Reporter: duncan |Owner:
Type: enhancement| Status: new
Priority: normal |Milestone:
On Tue, Jun 02, 2009 at 10:26:34AM +0100, Duncan Coutts wrote:
I'd like to get Hackage using the new check for base being bounded
above. I think it'll make a big difference when it comes to future
ghc/base upgrades. The last one was papered over by cabal-install
defaulting to base 3 when the
#435: ban upwardly open version ranges in dependencies on base
+---
Reporter: duncan |Owner:
Type: enhancement| Status: new
Priority: normal |Milestone:
On Tue, Jun 02, 2009 at 10:26:34AM +0100, Duncan Coutts wrote:
You mentioned in the ticket that we need to have base strictly following
the PVP. That's true of course. I'm assured by the GHC hackers that
they're committed to the PVP. The reason for bumping 4.0 - 4.1 is being
looked at but
Mon Jun 1 14:49:18 PDT 2009 rubbernecking.trumpet.step...@blacksapphire.com
* Make message refers to a library which is defined within the same.. more
grammatical
Ignore-this: 3887c33ff39105f3483ca97a7f05f3eb
M ./Distribution/Simple/Configure.hs -1 +1
View patch online:
Mon Jun 1 14:56:51 PDT 2009 rubbernecking.trumpet.step...@blacksapphire.com
* Ticket #89 final: Regression tests for new dependency behaviour.
Ignore-this: 52e04d50f1d045a14706096413c19a85
M ./tests/PackageTests/BuildDeps/InternalLibrary0/Check.hs -4 +4
A
#330: Support general documentation, not just haddock
+---
Reporter: fons |Owner:
Type: enhancement| Status: new
Priority: normal |Milestone:
On Tue, Jun 2, 2009 at 2:27 PM, Ian Lynagh ig...@earth.li wrote:
On Tue, Jun 02, 2009 at 10:26:34AM +0100, Duncan Coutts wrote:
You mentioned in the ticket that we need to have base strictly following
the PVP. That's true of course. I'm assured by the GHC hackers that
they're committed
On Tue, Jun 02, 2009 at 03:29:57PM +0200, Johan Tibell wrote:
If network's dependencies don't follow PVP so can't network itself,
etc.
I don't follow that; network can follow the PvP even if its dependencies
don't.
Thanks
Ian
___
cabal-devel
#559: Only allow dependencies on meta-packages from other meta-packages
+---
Reporter: guest |Owner:
Type: enhancement| Status: new
Priority: normal |
#559: Only allow dependencies on meta-packages from other meta-packages
+---
Reporter: guest |Owner:
Type: enhancement| Status: new
Priority: normal |
#185: Temporary executables leave foo.exe.manifest files behind
+---
Reporter: guest |Owner:
Type: defect | Status: closed
Priority: low|Milestone: _|_
On Tue, Jun 02, 2009 at 01:27:48PM +0100, Ian Lynagh wrote:
The reason base's version was bumped from 4.0 to 4.1 is that there were
some changes that required it, according to the PvP, e.g.
GHC.Conc.signalHandlerLock
was removed.
I don't know if there were any such changes in non-GHC.*
On Tue, Jun 02, 2009 at 08:03:55PM +0100, Ross Paterson wrote:
On Tue, Jun 02, 2009 at 01:27:48PM +0100, Ian Lynagh wrote:
The reason base's version was bumped from 4.0 to 4.1 is that there were
some changes that required it, according to the PvP, e.g.
GHC.Conc.signalHandlerLock
was
On Tue, Jun 02, 2009 at 08:53:19PM +0100, Ian Lynagh wrote:
I don't think the base split made much difference.
It forced the exposure of a lot more GHC.* modules, I think.
But I think my question is answered: just use base 5 or base == 4.*
___
On Tue, Jun 02, 2009 at 09:19:44PM +0100, Ross Paterson wrote:
On Tue, Jun 02, 2009 at 08:53:19PM +0100, Ian Lynagh wrote:
I don't think the base split made much difference.
It forced the exposure of a lot more GHC.* modules, I think.
In 6.6.1, before any splitting, there were no hidden
21 matches
Mail list logo
