[arch-haskell] trying to understand haskell-platform on Arch

[Magnus Therning]

On Wed, Aug 5, 2009 at 1:43 PM, Thomas Girod<thomas at 0xc29.net> wrote:
> Hi list,
>
> I have questions about how the haskell-platform is working with Arch. I must be
> missing something, please correct me :
>
> - The haskell-platform package is a bundle of libraries/tools of specific
>  versions that works well together
> - Each new version of the haskell-platform updates those libraries/tools to a
>  more recent versions
>
> But then, when I look at the PKGBUILD of haskell-platform, why does it have all
> the content of the platform declared as dependencies ? And if everything is
> installed as dependencies, why is the haskell-platform tarball downloaded
> anyway ?

Take a look in the tar-ball, it doesn't actually _contain_ all the
packages.  Think of haskell-platform as a meta-package, its main
purpose is to pull in other packages by depending on them.

>> depends=('gmp' 'ghc' 'haskell-cabal' 'haskell-glut=2.1.1.2'
>> 'haskell-http=4000.0.6' 'haskell-opengl=2.2.1.1' 'haskell-cgi=3001.1.7.1'
>> 'haskell-editline=0.2.1.0' 'haskell-fgl=5.4.2.2' 'haskell-network=2.2.1.4'
>> 'haskell-time=1.1.2.4' 'haskell-zlib=0.5.0.0' 'cabal-install' 'alex' 'happy'
>> 'haddock')
>
> Right now haskell-platform fails to install because community repo contains
> haskell-http version 4000.0.7, while AUR contains the 4000.0.6 version, and
> yaourt somehow fails to pick the right version - the problem can be solved
> easily, but needs human intervention.
>
> As all libraries/tools included in haskell-platform have their own independent
> release-cycles on Hackage, does it mean that the "Hackage -> AUR bridge" delays
> the releases of haskell-platform dependencies so they match the
> haskell-platform release cycle ?

This is a relevant question, and it needs solving.  I already got
bitten by this when installing the earlier version of
haskell-platform, that time it was also http that caused a diamond
situation.

One possibility is that it'll take care of itself once:

 1. GHC is distributed without the "base packages", this'll happen in 6.12 AFAIU
 2. Haskell-platform (and its dependencies) moves into [community]

Then I think haskell-platform should depend on a specific version of
ghc ("ghc=6.12", possibly even on a minor version "ghc=6.12.1") so
that it becomes more difficult to end up in the situation where GHC
"forgets" about all installed packages.  Haskell-platform will have
dependencies on specific versions of packages, and will hence prevent
its dependencies to be out of synch with itself.

Yes, this means that upgrading almost anything requires a lot of
building, but that seems to be the price one has to pay to package GHC
at the moment (if you want more proof read the Debian policy on
Haskell :-).

It'd also mean that packages that are part of HP, but which receive
updates out-of-synch with HP, must be available under a different name
(e.g. haskell-bleeding-edge-http :-) for people who want that.
(Another option is to say we don't do that, and encourage people to
use cabal-install instead.  Installing such bleeding-edge packages
next to HP is likely to result in versioning problems anyway.)

> I wonder why the haskell-platform PKGBUILD doesn't declare its content by using
> the "provides" parameter, and avoid conflicts with the latest versions of those
> libraries on AUR by also listing them in the "replaces" parameter.

I believe my comment above, after looking inside the tar-ball, makes
it obvious why it is this way.

/M

-- 
Magnus Therning                        (OpenPGP: 0xAB4DFBA4)
magnus＠therning．org          Jabber: magnus＠therning．org
http://therning.org/magnus         identi.ca|twitter: magthe