On Mon, 18 Jan 2010 15:50:37 -0800
Don Stewart
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@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell