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

9 Oct 2010

      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

There are a total of 4528 files in the (git) repo and 'du -sh' says that it
takes 57M.

/M

-- 
Magnus Therning                        (OpenPGP: 0xAB4DFBA4)
magnus＠therning．org           Jabber: magnus＠therning．org
http://therning.org/magnus         identi.ca|twitter: magthe