[Hackage] #428: cabal update uses too much bandwidth
Hackage
cvs-ghc at haskell.org
Thu Nov 4 10:31:19 EDT 2010
#428: cabal update uses too much bandwidth
--------------------------------+-------------------------------------------
Reporter: claus | Type: defect
Status: new | Priority: normal
Milestone: cabal-install-0.8 | Component: cabal-install tool
Version: 1.6.0.1 | Severity: normal
Keywords: | Difficulty: hard (< 1 day)
Ghcversion: 6.8.3 | Platform:
--------------------------------+-------------------------------------------
Comment(by claus):
I just found another reason why this is annoying: when using `--remote-
repo`, cabal requires `update`, and that will always re-download the huge
hackage index as well as the tiny index for the remote repo. Not to
mention that we still have to re-download the huge index every time we
want to install a newly updloaded package.
The compressed index has now grown to over 2MB!
Given that hackage only adds, almost never removes packages, why not have
checkpoints of the index every week, and daily tarballs with just the
added-since-checkpoint .cabal` files? Then cabal could download just the
dailies, starting from the last downloaded local checkpoint.
Very little additional technology - just untar the dailies on top of the
last checkpoint (if the repo doesn't support dailies, fall back to the
current scheme; for hackage, one could either have a server-side script
selecting the dailies, or even let cabal do that client-side - the former
being more efficient, the latter placing fewer burdens on non-hackage repo
providers).
--
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/428#comment:6>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects
More information about the cabal-devel
mailing list