
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 [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!)

On Mon, 18 Jan 2010 15:50:37 -0800
"Don" == Don Stewart
wrote:
Don> 2. Should Arch provide the binary Haskell Platform set in Don> [extra] and [community] (+ any other popular executables), and the Don> newest version of everything else that forms a coherent install Don> plan, in AUR. I believe it's reasonable to support HP for those who wants more stable and supported development platform with easy install via binary pacakges. So, +1 here for it. Don> * Arch Linux supports precisely the Haskell Platform spec, in Don> its binary repos. +1 Don> * AUR supports the latest version of a maximal install plan from Don> Hackage, separately. +1 Don> The consequence of this policy will be that no binary packages are Don> upgraded until the HP is updated. This should make vegai's work Don> easier. +1 Don> ** It would also mean downgrading ghc 6.12 back to 6.10.4 ** Does it mean we need 'ghc-dev' or something in AUR? Don> [1]: A 'coherent install plan' is the largest set of hackage Don> packages that build together, depending only on one unique version Don> for each library. (That is no QC1 + QC2. Pick one!) Huh, latest haskell-testpack says: QuickCheck (>=1.0 && <2.0) and it is dep for haskell-hdbc-2.2.2 (updated yesterday) on AUR which has only QC-2.1.0.2. How is this supposed to work? Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ----------------------------------------------------------------

On 18/01/10 23:50, Don Stewart wrote: [..]
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.
Sounds good to me, though we may need to add more binary packages to satisfy build dependencies of programs written in Haskell that make it into the Arch repos. As an example darcs now depends on dataenc, but dataenc is not in HP.
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 **
I thought you said in another mail that the next version of HP will be released once GHC 6.12.1 is released. 6.12.1 seems to be released already (it's what's on my system after a recent upgrade) so I assume a new version of HP is in the works already ;-) Rather than downgrading, would it be feasible for Arch to track HP as it moves to a release based on 6.12? It'd be more work, but downgrading seems like a pain for users. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus@therning.org http://therning.org/magnus identi.ca|twitter: magthe

magnus:
I thought you said in another mail that the next version of HP will be released once GHC 6.12.1 is released. 6.12.1 seems to be released already
"Once", but not "immediately once".
(it's what's on my system after a recent upgrade) so I assume a new version of HP is in the works already ;-) Rather than downgrading, would it be feasible for Arch to track HP as it moves to a release based on 6.12?
I think now we don't need to downgrade. We're on track: http://haskell.org/haskellwiki/Arch_Linux/6.12_Upgrade Most of those tasks are done now. -- Don

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

On Tue, Jan 19, 2010 at 9:25 AM, Xyne
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.
The biggest problem I see is that while GHC supports having multiple version of the same module available at the same time, pacman doesn't. That would mean that keeping a binary and an AUR version of the same package requires that they have different names. Not a big problem really, but it should be policed a bit. The bigger problem that users *will* run into is diamond dependency issues (A uses B and C, both B and C use D but different versions). I believe that avoiding that would require a *very* strict policy on what goes into both binary repos and AUR. Too strict to follow the "Arch way", I think.
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.
This is an interesting idea, especially if we get some tool support for that. AFAIK all "AUR builders" (yaourt, paktahn, etc) only know about AUR, so they need to be made a bit more configurable. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus@therning.org http://therning.org/magnus identi.ca|twitter: magthe

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.
This is an interesting idea, especially if we get some tool support for that. AFAIK all "AUR builders" (yaourt, paktahn, etc) only know about AUR, so they need to be made a bit more configurable.
The official repos along with some others, such as my own, include a tarball named $repo.abs.tar.gz. This tarball contains all of the PKGBUILDs and local source files required to build the packages in the given repo from source. If someone were able to provide the aforementioned Haskell repos with these archives included, Bauerbill would already be able to build from them as it uses these archives to build from source (which was a design decision to make it more versatile than it would have been had it used the official ABS tree). If such a scheme is not possible, I would still be willing to try to implement support for an alternative scheme.
The biggest problem I see is that while GHC supports having multiple version of the same module available at the same time, pacman doesn't. That would mean that keeping a binary and an AUR version of the same package requires that they have different names. Not a big problem really, but it should be policed a bit.
The bigger problem that users *will* run into is diamond dependency issues (A uses B and C, both B and C use D but different versions). I believe that avoiding that would require a *very* strict policy on what goes into both binary repos and AUR. Too strict to follow the "Arch way", I think.
If a reasonable naming scheme is chosen and if different versions of the same package can install to different locations to avoid file conflicts, you can use "provides" without "conflicts" to satisfy such dependencies. As already mentioned, this might expose limitations with some AUR frontends, but it would be ridiculous to work around such limitations rather than expect the developers of those applications to address them. The viability of this probably depends on how many versions of each package one would have to support. If there would only be one version per ghc version, then maybe this could be included in the name, or if they are targeted at different releases of the Haskell platform then use that version in the name. It should also be possible to create a tool to manage Haskell packages (installation of specified versions, dependency resolution, etc) that could then update Pacman's local database to enable global removal of such packages with Pacman while leaving the complexities of finer management to a dedicated tool. This would necessarily add some complexity but it might lead to less complexity overall by eliminating the need to manage multiple versions of packages across the repos and the AUR. It should also provide finer control to users who need it. This way you would only need to manage the latest stable releases in the repos and the AUR and users who need something else could handle that themselves with this tool.

Just my votes. On 01/19/2010 12:50 AM, Don Stewart wrote:
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.
+1 * even if it would mean downgrading 6.12.1 to 6.10.4 * the binary version should be the stable one, if somebody wants to be very up to date, then aur is for him/her It would be also good to have the latest ghc package in aur which sometimes/often would be newer than the binary package in extra. Having more repositories for haskell packages (based on which ghc version they depend on) looks nice but I personally do not really care. Extra and aur sounds good enough. I like the idea that all haskell package dependencies will be in the provides list (even when there are some tools (yaourt) which do not support it now - the bug should be fixed where it is (yaourt)). Thanks for working on this, Peter.
participants (5)
-
Don Stewart
-
Gour
-
Magnus Therning
-
Peter Hercek
-
Xyne