[Hackage] #462: Automatic rebuild of depending packages once failed dependency re-uploaded and builds.

[Hackage]

#462: Automatic rebuild of depending packages once failed dependency re-uploaded
and builds.
--------------------------------+-------------------------------------------
  Reporter:  golubovsky         |        Owner:                
      Type:  enhancement        |       Status:  new           
  Priority:  normal             |    Milestone:  _|_           
 Component:  hackageDB website  |      Version:                
  Severity:  normal             |   Resolution:                
  Keywords:                     |   Difficulty:  hard (< 1 day)
Ghcversion:  6.10.1             |     Platform:                
--------------------------------+-------------------------------------------
Comment (by mokus):

 Replying to [comment:8 malcolm.wallace at cs.york.ac.uk]:
 > So it seems to me that a purely-documentation build does not (or should
 not) need any of the depended-upon packages to be available, which would
 solve the immediate problem reported in this ticket.

 In theory it should not.  In practice there is at least two cases that
 would require careful attention:

     1) I believe haddock evaluates any template-haskell splices in the
 code it's processing (though I could be wrong on that).

     2) Setup.hs may itself depend on some of the build-depends.  I don't
 know whether this sort of thing actually happens, and it seems to me that
 it ought to be discouraged anyway because of the implicit chicken-and-egg
 problem.  This case could probably be reasonably written off as something
 to "do at your own risk".

 Neither of those is insurmountable, obviously, but they do spring to my
 mind at least as potential challenges.  Both cases could be handled by
 aggressive preconditioning by "cabal sdist", or perhaps it would still be
 reasonable to just do a full build in such cases and any other exceptional
 circumstances that may exist.

 I don't know how deep the difficulties Isaac Dupree mentions run, but even
 if they can be handled by clever caching of type and documentation
 information (which I suspect), the implementation of such a system would
 probably be far from trivial.

-- 
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/462#comment:10>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects