library packages and Debian

[Ross Paterson]

[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.