Re: [arch-haskell] What to do now?

On Sat, 09 Oct 2010 22:13:50 +0100, Magnus Therning wrote:

On 09/10/10 09:43, Rémy Oudompheng wrote:

...

Magnus Therning :

...

On 08/10/10 23:04, Peter Simons wrote:

...

...

...

Do we try to do something like what Xyne suggested--set up a Haskell ABS and publish pre-compiled packages in [arch-haskell]?

...however, in the spirit of Arch (in comparison with the Gentoo which I left 3yrs ago), I consider that having kind of 'Haskell overlay' with binary packages would be very nice...

Yes, I agree that this is probably the best solution. Arch was designed to work that way. How difficult is it to set up a repository? Does anyone know how to do that?

I think there are a few Arch devs reading this list, at least a TU or two, hopefully they can offer some more information.

AFAIU it's not much to it really. An ABS-like tree (perhaps kept in a Darcs repo for extra points :-) and a place to upload binary packages and the repo DB to.

I support that idea. I would really like to host that on the same server as [community] and [multilib] repos, if the total size of the repositories is not too big, but I fear it would be several gigabytes. I imagine: - keeping ghc + several basic modules in extra/community for bootstrapping - a darcs repo one for the scripts * a script that builds packages (possibly inspired by devtools, for example an analogue of archbuild taking multiple arguments) * a script handling rebuilds (build all reverse dependencies of something in the right order) possibly just an option to the previous script * a script that updates a given collection of PKGBUILDs by calling cabal2arch * a script that moves built packages to the repositories (like commitpkg in devtools) - a darcs repo for the PKGBUILDs

1. Are you suggesting we keep binary versions of *all* of hackage in a repo, or 2. we keep PKGBUILDs for all of hackage in an ABS tree, and only provide binaries for a subset of packages?

...

* one dir per package, and subdirs $package/trunk, $package/repo (holding the current WIP version of the PKGBUILD and one corresponding to the binary package in repo) * people are supposed to do only a partial checkout of the darcs repo, I know Git can do that, but that said, a full working copy is only a few thousand files. Is darcs as efficient as Git for storage ? I expect the transfer size for a full cloning to be less than 5MB.

It's worth clarifying here that while git does support partial checkout it doesn't support partial cloning. darcs supports lazy cloning, and I think git does as well.

Just to get some numbers I downloaded the cabal files for for the latest version of all packages on Hackage. Then I ran cabal2arch on it all. After that I attempted to put the results in darcs and git.

Adding all files, 100 at a time:

* darcs: 522.18s user 5.49s system 99% cpu 8:48.96 total * git: 1.90s user 0.77s system 97% cpu 2.726 total

Record/commit of initial changeset:

* darcs: NA, it seems frozen with: 5548 done, 5480 queued * git: 0.33s user 0.32s system 57% cpu 1.128 total

I would suggest to use git for this kind of larges repos, however darcs will be a lot happier with smaller patches (even one per new file), making tags from time to time helps as well since it trunks the inventory and makes some operations cheaper. -- Nicolas Pouillard http://nicolaspouillard.fr