On Sat, Jan 16, 2010 at 5:04 AM, Magnus Therning wrote:

I thought 6.10 came with Cabal as well, and that it was dealt with by having 'ghc' provide 'haskell-cabal' in Arch. These points are all true, but yaourt (the tool most people use and what's recommended in the wiki) doesn't seem to respect this and it seems kind of odd to me to have haskell-cabal an an explicit dep when none of ghc's other known provided packages are made explicit. Finally and most importantly, the main issue is that these are literally the only dependencies being generated. For example, many new 6.12 packages require mtl, but that's not being placed in the depends array.

* On Saturday, January 16 2010, Tasha Buckley wrote:

On Sat, Jan 16, 2010 at 5:04 AM, Magnus Therning wrote:

...

I thought 6.10 came with Cabal as well, and that it was dealt with by having 'ghc' provide 'haskell-cabal' in Arch. These points are all true, but yaourt (the tool most people use and what's recommended in the wiki) doesn't seem to respect this and it seems kind of odd to me to have haskell-cabal an an explicit dep when none of ghc's other known provided packages are made explicit. Finally and most importantly, the main issue is that these are literally the only dependencies being generated. For example, many new 6.12 packages require mtl, but that's not being placed in the depends array.

This is a simple change in cabal2arch: corePackages :: [Dependency] ... -- removed: ,Dependency (PackageName "mtl") (ThisVersion (Version [1,1,0,2] [])) ... But I'll hold off on sending a patch right away, since I think that other core packages (those provided by ghc-6.12) have also changed. -- Adam

* On Saturday, January 16 2010, Don Stewart wrote: ...

Right, that's the usual 'ghc major update' diff.

I'll take care of it. The list just has to match this page:

http://haskell.org/haskellwiki/Libraries_released_with_GHC

-- Don

It might be sensible to remove the use of corePackages in: ] removeCoreFrom :: [Dependency] -> [Dependency] Considering the current ghc now provides haskell-* packages for all of it's core libraries: Provides : haskell-array=0.3.0.0 haskell-bytestring=0.9.1.5 haskell-cabal=1.8.0.2 haskell-containers=0.3.0.0 haskell-directory=1.0.1.0 haskell-extensible-exceptions=0.1.1.1 haskell-filepath=1.1.0.3 haskell-haskell98=1.0.1.1 haskell-hpc=0.5.0.4 haskell-old-locale=1.0.0.2 haskell-old-time=1.0.0.3 haskell-pretty=1.0.1.1 haskell-process=1.0.1.2 haskell-random=1.0.0.2 haskell-syb=0.1.0.2 haskell-template-haskell=2.4.0.0 haskell-time=1.1.4 haskell-unix=2.4.0.0 haskell-utf8-string=0.3.4 That would make all library dependencies explicit (well other than base). If ghc continues to reduce the set of core libraries (ex. mtl is missing from 6.12), pkgbuilds will have to be updated less frequently. But perhaps such a change isn't worth the extra time pacman will then take to resolve dependencies... and also other bugs in yaourt it might expose. -- Adam

On Sat, Jan 16, 2010 at 8:18 PM, Adam Vogt wrote: [..]

] removeCoreFrom :: [Dependency] -> [Dependency]

Considering the current ghc now provides haskell-* packages for all of it's core libraries:

  Provides       : haskell-array=0.3.0.0  haskell-bytestring=0.9.1.5  haskell-cabal=1.8.0.2                    haskell-containers=0.3.0.0  haskell-directory=1.0.1.0                    haskell-extensible-exceptions=0.1.1.1  haskell-filepath=1.1.0.3                    haskell-haskell98=1.0.1.1  haskell-hpc=0.5.0.4                    haskell-old-locale=1.0.0.2  haskell-old-time=1.0.0.3                    haskell-pretty=1.0.1.1  haskell-process=1.0.1.2  haskell-random=1.0.0.2                    haskell-syb=0.1.0.2  haskell-template-haskell=2.4.0.0                    haskell-time=1.1.4  haskell-unix=2.4.0.0  haskell-utf8-string=0.3.4

That would make all library dependencies explicit (well other than base). If ghc continues to reduce the set of core libraries (ex. mtl is missing from 6.12), pkgbuilds will have to be updated less frequently.

I think that is the Correct Way to do it!

But perhaps such a change isn't worth the extra time pacman will then take to resolve dependencies... and also other bugs in yaourt it might expose.

IMHO these are fairly silly reasons, pacman's dependency resolution may be slow, but it is insignificant compared to other stages during package building, for installing pre-built packages it might be more significant but I strongly doubt that it's enough to put people off. As for exposing bugs in yaourt, surely this is only good, isn't it? ;-) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe