[arch-haskell] arch-haskell repo and ABS tree

Xyne xyne at archlinux.ca
Thu Oct 7 16:33:42 EDT 2010


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.

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.

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.


> Currently, I'm one week backed up on AUR updates -- but it is indeed
> getting out of hand: hackage is averaging 15 packages a day uploaded
> now, but spikes up to 30 packages a day. That's getting hard to stay on
> top of. The tools for tracking aren't yet in a state to support
> distrbuted maintainance either (though they're close)

That's why I wrote that the delays are understandable. The current approach
does simply not scale well and I think it's worth considering other approaches.
Just to be extra clear, I am in no way criticizing you. I think you've done a
great job of supporting Haskell on Arch.



More information about the arch-haskell mailing list