On Thu, Oct 7, 2010 at 21:33, Xyne
On 2010-10-07 11:54 -0700 (40:4) Don Stewart wrote:
xyne:
Hi,
I want to suggest that the Arch Haskell group create their own repo and ABS tree, and withdraw from the AUR.
Requests to orphan neglected haskell packages come up relatively often on the aur-general mailing list and the lack of active support is a cause of frustration, even if it is understandable.
Creating a separate binary repo and an ABS tree would provide consistency and could be made official (maybe hosted on archlinux.org and mirrored, or hackage). Users who wish to maintain haskell packages in the AUR could then do so without interfering with global consistency. Those who need newer packages could enable the AUR via e.g. bauerbill and those who simply wish to have access to the full set provided by Arch Haskell would enable the repo or build from its ABS tree. Maybe I could even provide support in bauerbill.
How do we manage the binary ABI incompatibilities? This was a problem last time we tried to maintain a large binary repo: each upgrade requires a topological rebuild of the downstream dependencies.
Couldn't you handle that with build scripts that track dependency hierarchies and rebuild as necessary? For example, when a package is upgraded all packages that depend on it (directly or indirectly) could be automatically rebuilt.
I think that would be possible, yes.
The idea would be to move all Haskell packages (i.e. including ghc and all others in the official repos) to this repo and manage them there. You would then have full control over the package hierarchy.
Considering the recent creation of [multilib], [haskell] or [arch-haskell] should be a strong candidate for official status.
It would be very nice to get that sort of recognition. I'd love being able to say that I run the most Haskell-friendly distro in the world ;-) One thing though, if ghc was taken out of [extra] then wouldn't this mean that no tool written in Haskell could ever make it into [extra]? (E.g. darcs)
The following is mostly thinking out loud, but this might also be a way to manage multiple versions of different packages. You could place all of the different versions in the same repo directory and then simply provide different databases container various subsets of those packages. I have an idea for a tool that could easily enable and disable databases on the user end so the user would not have to update pacman.conf manually. Meh, it's just a tangential idea... although I'm going to test something now.
Any ideas on how to bootstrap this, and also how to build a team for it? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe