[rather Debian-specific, I'm afraid] On the Wiki, two solutions to the problem of N compilers and M libraries are proposed: 1. NxM binary packages (x number of architectures) 2. M packages, compiled with the available compilers on installation, and recompiled on upgrade. and Ganesh writes:
I think solution 2 is horrible; building Haskell code can take a long time, and it opens users up to experiencing failures at package install time. Compiling code is something that properly belongs at package build time. Solution 1 admittedly has the drawbacks mentioned, but as long as timely updates happen (e.g. when a new release of GHC appears) it's superior.
Agreed. 2 also requires the user to have a build environment (with more packages), but the failure at upgrade time is the worst problem. Suppose I have several compilers and libraries installed, and one day I upgrade the system, get a new version of GHC, and for whatever reason one of the library packages I have installed doesn't work with that version. My system is broken. Would the following work? - one source package per library package, generating a binary package for each compiler (and each architecture). Debian maintainer for the package gets it working with each compiler, and records dependencies on specific version numbers of each compiler in the control file. (Maybe there are compiler- and architecture-independent packages too.) - when a Debian package of a compiler is upgraded, the Debian maintainer for that compiler also performs (preferably automatically) a non-maintainer upload for each library package, in which the only change is to the version number of that compiler that the library package depends on. Would not the autobuilder then do the rest? Then if the compiler upgrade causes some library package to fail, the user will see a conflict: they either remove the library package or postpone the compiler upgrade. This only checks build failures, but library authors and maintainers could include tests in the build process. Might be a bit hard on the autobuilders, of course.