We need a process for requesting addition of system libraries to hackage server machine
E.g., we may have a list of system libraries in the repo that a cron script reads and apt-get-installs the libs (in the future, it might also add extra apt sources first). Then people that need a lib can create a PR that modifies the list.
Use case: I badgered @bgamari to no end about libsdl2-ttf-dev that vanished at some system upgrade and so package sdl2-ttf didn't build (and so no haddocs were generated, but that can be amended by manual upload) and the following report said the package became broken
https://matrix.hackage.haskell.org/package/sdl2-ttf#GHC-8.0/sdl2-ttf-0.2.2
Now the package is reported as OK, because libsdl2-ttf-dev was installed manually. If there was a process, I'd just create a PR and also we'd be sure the system lib doesn't vanish in the future, as it did previously.
We'd also need to document the process on https://hackage.haskell.org and make sure people that look for it don't enter the current wiki page "Submitting changes for the core libraries", but the relevant one (to be written).
This is quite relevant to http://matrix.hackage.haskell.org/ as well (which at some point may take over documentation generation). I currently maintain a manual list of -dev packages so I can keep all build-nodes in sync...
Oh, I was under the false impression the hackage proper and matrix already share the list of system libraries. Somehow.
Well, Hackage actually uses a doc-builder bot which runs on a separate machine (obviously - you don't want packages be able to bring down the hackage instance). In fact, I don't even have access to the doc-builder currently...
Seeing how much work maintaining doc builder is (e.g., upgrading the Ubuntu distribution so that newer versions of packages can be installed, because people's projects depend on the new versions), I'm now thinking if it would be better if the doc builder was turned off completely, but building docs was added by default to cabal sdist and docs included, by default, in the main tarball that gets uploaded to Hackage.
@Mikolaj Well, yes and no... my long-term idea is to have matrix.hho take over doc building (since matrix.hho already needs to be able to build most of what gets upload to Hackage that matters anyway, otherwise it can't achieve its mission goal), but for that we need cabal new-haddock working.
Oh, that would be awesome. If so, a process for badgering you (or any of the future crowd of auxiliary matrix maintainers) would be useful. But even then we still need better(-documented) tools for user-created haddocks for the packages with exotic, bleeding-edge or mutually-exclusive dependencies. Anyway, hats off to you and Ben for the tons of great work you are doing --- I had no idea how much work it is, until I actually tried to help instead of just complaining. :)
Short of this process, it would be nice if there were a place that listed which libraries are already installed on the doc builders / matrix in the interim.
There's a draft gsoc proposal that addresses improving docbuilder btw, but I don't know of any sort of technical idea which could be added to it that might help address the system library situation: https://github.com/haskell-org/summer-of-haskell/pull/76/commits/49818ba9e15403c3b7c472e6555118cf62cab318
(proposals welcome!)
This I think would be resolved from linking to https://github.com/haskell-infra/hackage-doc-builder-config which ben mentioned in #730