[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.
On Fri, 12 Sep 2003 10:38:32 +0100, Ross Paterson
- 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.
It's worth considering for the NMU to use the delayed queue (say 3 days). This would give the proper maintainer a chance to check things manually and make any updates needed. Obviously there's a balance to be struck between timely availability and reducing the changes of broken packages, so this is one variable that can be tweaked to get this balance right. Ganesh
On Fri, Sep 12, 2003 at 10:38:32AM +0100, Ross Paterson wrote:
[rather Debian-specific, I'm afraid]
...
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.)
No. Debian only allows build-depends on a per-source package basis, so this would mean that the library would be restricted to platforms on which all haskell compilers exist. -- David Roundy http://www.abridgegame.org
On Sat, Sep 13, 2003 at 12:19:53PM -0400, David Roundy wrote:
On Fri, Sep 12, 2003 at 10:38:32AM +0100, Ross Paterson wrote:
[rather Debian-specific, I'm afraid]
...
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.)
No. Debian only allows build-depends on a per-source package basis, so this would mean that the library would be restricted to platforms on which all haskell compilers exist.
ghc6 build-depends on gcc-2.95 [sparc] meaning gcc-2.95 is needed on sparc only. The problem as I see it is that either you have to make the build-deps stricter than they need to be to force things to build with the latest compiler version or you need to wait for the buildds to build the new compiler on all arches before uploading the libraries. This wouldn't be so bad if the chances of all the buildds actually working at any given time was better, although a binary upload could be done by hand for the one or two broken ones. The first option means that someone who has an older compiler (backporting to stable, don't want to upgrade to the latest version for some reason, or whatever) can't tell the difference between a library trying to build with this version and one which won't build with earlier versions. Thanks Ian
On Mon, Sep 15, 2003 at 01:24:40PM +0100, Ian Lynagh wrote:
No. Debian only allows build-depends on a per-source package basis, so this would mean that the library would be restricted to platforms on which all haskell compilers exist.
ghc6 build-depends on gcc-2.95 [sparc] meaning gcc-2.95 is needed on sparc only.
Ah, I didn't realize you could do that... but this would mean every library package would have encoded into it which compilers are avaliable on which platforms, which seems like a waste. I guess a better way to do this would be to have a package "all-haskell-compilers" which on each platform depends on all available haskell compilers, and then library packages could just depend on that.
The problem as I see it is that either you have to make the build-deps stricter than they need to be to force things to build with the latest compiler version or you need to wait for the buildds to build the new compiler on all arches before uploading the libraries. This wouldn't be so bad if the chances of all the buildds actually working at any given time was better, although a binary upload could be done by hand for the one or two broken ones.
Another problem (and this is *very* debian-specific) would be that *every* haskell library and compiler would have to simultaneously move from unstable into testing, along with all libraries that have haskell bindings.
The first option means that someone who has an older compiler (backporting to stable, don't want to upgrade to the latest version for some reason, or whatever) can't tell the difference between a library trying to build with this version and one which won't build with earlier versions.
I would assume that using option one the depends would be used to indicate what kind of compiler it works with (besides being used to indicate what -dev packages are required). -- David Roundy http://www.abridgegame.org
participants (4)
-
David Roundy -
Ganesh Sittampalam -
Ian Lynagh -
Ross Paterson