[arch-haskell] What to do now?

[Nicolas Pouillard]

On Sat, 09 Oct 2010 22:13:50 +0100, Magnus Therning <magnus at therning.org> wrote:
> On 09/10/10 09:43, Rémy Oudompheng wrote:
> > Magnus Therning <magnus at therning.org>:
> >> 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