[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