#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