#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

#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 duncan): The simplest solution would be to use cabal-install rather than `runghc Setup`. cabal-install will rebuild things as appropriate to avoid the diamond dependency problem. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/598#comment:4 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects

#598: Bogus build failures on HackageDB --------------------------------+------------------------------------------- Reporter: mboes | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- Comment(by duncan): Replying to [comment:5 ross]:

It will rebuild package versions that are already installed?

Probably saves trouble in the long run, though it would be annoying if

Exactly. It rebuilds them against different versions of their dependencies, so that the overall installation plan (graph) is consistent. It tries where possible to reuse existing installed package instances. the rebuild failed. Hopefully it would not matter since you wouldn't be uploading the results of dependent package rebuilds, just the single target package you're interested in. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/598#comment:6 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects

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

Comment(by ross):

 Replying to [comment:4 duncan]:
 > The simplest solution would be to use cabal-install rather than `runghc
 Setup`. cabal-install will rebuild things as appropriate to avoid the
 diamond dependency problem.
 To generate the documentation for a package, one must
  * build, haddock and install all pre-requisite packages
  * do the equivalent of
    {{{
 runghc Setup.hs configure --ghc --user --haddock-option=--use-
 contents=http://hackage.haskell.org/package/
 runghc Setup.hs haddock '--html-
 location=http://hackage.haskell.org/packages/archive/$pkg/$version/doc/html'
 --hyperlink-source
 runghc Setup.hs haddock --hoogle
 }}}
 From hunting through the code, it seems the planning stuff only happens if
 I use the "install" subcommand, but that doesn't take the haddock options
 I want to use.

 What are the cabal-install commands I should be using?

-- 
Ticket URL: 
Hackage 
Hackage: Cabal and related projects