Hi, Am Dienstag, den 01.06.2010, 21:50 -0300 schrieb Marco Túlio Gontijo e Silva: > Excerpts from Joachim Breitner's message of Sex Mai 07 10:56:17 -0300 2010: > (...) > > One big problem is cyclical dependencies. Assume we start building > > libraries including leksah meta data. Then leksah-server would be a > > build dependency for every haskell package. But to build leksah-server, > > we need to build mtl first – a classical chicken-and-egg problem. For > > tools like hscolour, it is not too bad, because they have no > > dependencies besides ghc6. > > > > Now this could be worked around by manually bootstrapping leksah once. > > Or by making the build not fail if no leksah is available, and then > > “bootstrap” packages with a “dummy leksah” package. Or something like > > this – our problem :-) > > > > I’m still doubtful that the ghc6 maintainer will be willing to add > > another dependency, so for the libraries shipped with ghc6, we have to > > think of something else. > > I thought about a solution to this problem. If leksah files were shipped in > another different package, we could build the -leksah packages from ghc6 and > the dependencies of leksah-server, like mtl, in the source package of > leksah-server. unfortunately, that would require having the _sources_ of ghc6, mtl etc. around at build time, which is not possible at the moment. We could copy the source tarballs to the leksah-server package (ugly) or create -source packages for ghc6, mtl etc. (also ugly, and also requires changes to ghc6). I think building them within ghc6 is not too bad if we make sure that it does not hinder buildability. My idea would be that haskell-devscripts Depends: leksah-mk-metadata | leksah-mk-metadata-dummy. leksah-mk-metadata would be a package providing a binary that creates the metadata file. leksah-mk-metadata-dummy is an arch:all package (thus always available as a fallback) that also provides the binary, but does not do anything. This way, builds can not fail because leksah-mk-metadata is not built on a certain architecture, but as soon as it is, we can fix it by using a binNMU. This requires that the buildds actually prefer the first choice of a Dependency, if available, but I think they do. Anyways, this is all mid-term-stuff, having leksah in Debian as it is now is the first step. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
Attachment:
signature.asc
Description: This is a digitally signed message part