[Hackage] #598: Bogus build failures on HackageDB

[Hackage]

#598: Bogus build failures on HackageDB
--------------------------------+-------------------------------------------
  Reporter:  mboes              |        Owner:         
      Type:  defect             |       Status:  new    
  Priority:  normal             |    Milestone:         
 Component:  hackageDB website  |      Version:         
  Severity:  normal             |   Resolution:         
  Keywords:                     |   Difficulty:  unknown
Ghcversion:                     |     Platform:         
--------------------------------+-------------------------------------------
Comment (by mokus):

 I'm getting extremely frustrated by situations very much like this one.
 the bytestring-0.9.1.5 update was particularly nasty and caused bogus
 failures in every package I uploaded for a couple months, to the point
 where i added hacks to one project's cabal file for the sole purpose of
 making it build on the hackage server.  It really should not be possible
 for a _._._.x version bump to wreak this kind of havoc.

 More recently, I uploaded a new version of my 'random-fu' package and it
 failed due to some problem which prevented the non-negative package from
 linking.  I have not looked into it just yet, but it looks like another of
 the same issues - essentially bitrot in the ghc-pkg database on whatever
 system does the hackage builds.  This is getting out of hand, in my
 opinion.

 I propose a few alternative solutions, varying in directness and
 complexity:
     1) all packages be rebuilt occasionally (say, monthly) from a clean
 Haskell-Platform install (preferably also updating the info on the web for
 packages that successfully rebuild)

     2) keep stats on reverse-dependency build failures, use a pagerank-
 like tool to propagate those stats up the graph, and rebuild packages and
 their dependencies when scores start to plummet (which presumably would
 have happened to bytestring shortly after 0.9.1.5 was uploaded and huge
 numbers of projects referencing it would not build)

     3) Just build *every* upload in its own clean package.conf environment
 as a fallback (instead of or in addition to the preferred-versions
 fallback), rebuilding all the package's dependencies as well like "cabal
 install" does.

 That last should be fairly simple to implement and would make a lot of
 sense to me, especially given that I think most users do something of the
 kind in their own pre-upload testing.  I know I do anyway.

 I would personally be satisfied if I could just get the haddock
 documentation to appear on the package archive page when the build fails.
 People can and will skim the package documentation and try building a
 package themselves if the package sounds interesting to them, but they're
 extremely unlikely to build the documentation just so that they can
 discover whether the package is interesting to them.

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