Replying to [comment:5 ross]:
Probably saves trouble in the long run, though it would be annoying if
#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 mokus): Replying to [comment:6 duncan]: 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. I may be wrong, but I think he was referring to the new uploader as the one being annoyed by such a situation, because they would know that there's a version of the package on which their upload depends already built on Hackage. I'd say that this annoyance is an acceptable risk, though - if an old package won't build in a particular configuration of the dependency graph, that's a legitimate build failure of the package which induced that graph, even if the fault is in the dependency. An end user very well may run into that same failure. The depended-upon package's maintainer should probably get notified if that happens, or the build failure should at least be recorded somewhere that the maintainer could easily find it without having to dig through other packages' build logs. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/598#comment:7 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects