[arch-haskell] Arch Haskell Policy Proposal

[Xyne]

On Mon, 18 Jan 2010 15:50:37 -0800
Don Stewart <dons at galois.com> wrote:

> So, the big question for the team is what versions of packages we
> support and where.
> 
>  1.  Should Arch track the newest version of every Hackage
>      package, in [extra], [community] or AUR?  (the current behaviour, mostly)
> 
> OR
> 
>  2.  Should Arch provide the binary Haskell Platform set in [extra] and
>      [community] (+ any other popular executables), and the newest version 
>      of everything else that forms a coherent install plan, in AUR.
> 
> Most other distros are trying to support the first half of 2. That is,
> they provide only what the Haskell Platform specifies (e.g. ghc 6.10.4 +
> other things), in binary form. 
> 
> Currently, we have a mixture of 6.12 + ad hoc set of packages in binary
> form, plus AUR is the latest of everything that I can construct a
> coherent install plan for [1].
> 
> This is a pressing issue, since the move to 6.12 has broken a lot of
> things -- mostly since the HP isn't moving to 6.12.x until 6.12.1 is
> out, and thus many libraries and tools aren't ready to support 6.12.
> 
> This will likely break many things for a few weeks at least.
> 
> I propose the following:
> 
>    * Arch Linux supports precisely the Haskell Platform spec, in its
>      binary repos.
> 
>    * AUR supports the latest version of a maximal install plan from
>      Hackage, separately.
> 
> The consequence of this policy will be that no binary packages are
> upgraded until the HP is updated. This should make vegai's work easier.
> 
> ** It would also mean downgrading ghc 6.12 back to 6.10.4 **
> 
> If there is consensus, we can adopt this as policy, refer to it on the
> website. Users who wish newer versions of things (such as ghc 6.12) can
> use AUR packages.
> 
> -- Don

Afaik, it is Arch's official policy to support the latest _stable_
releases of upstream packages, which means that 2 is the only
acceptable choice. I would also recommend downgrading if you expect the
problems caused by the early push to last for several weeks. You can
always push the new version to [testing] instead but such breakage
should not occur in the main official repos (core, extra, community).

Would this plan preclude compatibility between binary and AUR packages?
One way of reading the proposal is that the binary packages in the
official repos would form one set and the packages in the AUR would
form a separate and mutually exclusive set that the user would be
required to keep apart. I am sorry if this question is ignorant but I
still do not fully understand the complexities of building haskell
packages. If this interpretation is correct then I would argue that the
AUR is intended to complement the official repos, not to act as an
alternative to them, but I hope that this interpretation is wrong.

Considering the complexity of this issue, perhaps it would be a good
idea to create independent haskell repos to host compatible binary
packages and/or an official AUR-clone for all of the current haskell
packages in the AUR. You could then support the latest stable versions
in the offical repos and maintain compatible packages for them in the
AUR, and let users who require the latest versions use the official
haskell repository and AUR-clone (or just cabal2arch) to acquire the
very latest versions.


> 
> [1]: A 'coherent install plan' is the largest set of hackage packages
> that build together, depending only on one unique version for each
> library. (That is no QC1 + QC2. Pick one!)
> _______________________________________________
> arch-haskell mailing list
> arch-haskell at haskell.org
> http://www.haskell.org/mailman/listinfo/arch-haskell