[arch-haskell] What to do now?
nicolas.pouillard at gmail.com
Sat Oct 12 07:36:42 UTC 2013
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,
> 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.
More information about the arch-haskell