Hi John, I've extracted among others two things you don't like too much about cabal: a) having to specify build dependencies because they may change (eg example split base or different libraries poviding network interfaces ..) b) Cabal can't do everything easily. Examples are the multi stage system of ghc or wxWidgets ... Can't say much to this point. For my needs cabal has been enough and packaging many package for NixOs has been easy (except adding foreign C lib dependencies) You would also prefer a build command which does never change solving the problem that you Setup.hs files maybe can't be read by Cabal vesrions of the future. You'd like to have a cabal independant package description so you can extract information easily? Maybe I got some things not right here.. Anyway, how does a package description look like which would satisfy the write once, let one true buildsystem build my package on foregin architectures, machines, distros without having me to change network to jhc-network or such? And probably without the burden for implementors to have to provide a network-1.0 compatible interface ? Let's talk about an example: module Main where import System.IO import ClassProvidingShowDerivedAB data A = ... {- derive .. - } main = do printLn $ showDerivedA $ A ... printLn $ showDerivedB $ A ... So the description must contain that we need - DrIft or the derive library (assuming that the derive library can read Drift syntax) - a foreign module (probably called ClassProvidingShowDerivedAB) providing showDerivedAB of type (A .. -> String) - a foreign module (probably called System.IO) providing printLn of type (String :: IO ()) where "a foreign module" may also mean or any other set of modules exporting the given functions.. So a configure system should find packages containing those functions beeing used and should know (or be able to figure out itself) that ClassProvidingShowDerivedAB has been split into ClassProvidingShowDerivedA ClassProvidingShowDerivedB on some systems? The type system of haskell will be able to give you much better matches compared to looking for C/C++ interfaces, but String -> IO () is not very uniq.. So how can this dependency be expressed? Only consider package dependencies having the word "network" in either its name or description? You could ask the configure system to test all functions String -> IO () wether they have the desired behaviour (hoping that none is implemnted as showDerivedA = const $ removeRecursive "/").. Anyway it would be quite interesting to see wether we can write an application guessing dependencies this way.. However I don't like this to be done automatically. Then the burden of writing the dependencies into a description file would even become smaller. If we want a package be buildable on a time frame of -10 years (past) -> now -> + 10 years (future) either the configure script or the configure system can check for different substitutes or versions which did exsist from -10 years in the past up to now. However we can't know the changes beeing made in the future or wether different substitutes will become availible.. However some "magic knowledge" could know about my lib and its dependencies at publication and know about changes having been made to dependencies up to now. Then it could try refactoring the published code to fit current versions of the libraries.. In the future maybe this magic knowledge can be found in darcs patches (it alread provides support to changing names to some degree..) or it could be collected by volunteers. Changes which could be resolved automatically are renaming , merging and splitting of functions or modules, refactorings such as adding additional parameters to functions etc.. This magic knowledge could be updated by running a tool such as autoreconf or whatsover.. I even think this could work quite well for if you have kind of package database such as hackage knowing about interface changes from package xx-1.0 to xx-2.0. But it would be hard to implement a refactoring tool which can refactor source containing some #ifdefs ? Wait, we could throw away many #ifdef GHC_VERSION > or < version x.y because the system would know about the differences? To uniqely define a set of transformations of your code which has been written using set of dependencies A so that it can be compiled on another system B you need something like a *.cabal file again to tell the nice configure and rewrite engine where to start.. This could look like this network-1.0 from hackage HaXmL git repo hash XXYYZZ Then you could tell the magic tool that instead of network-1.0 jhc-network-0.8 can be tried.. I would really appriciate such a magic tool knowing abouth thousands of changes/ refactorings a) if it knows a transformation I can just run it and compile b) if it knows the difference but there is no transformation maybe there is a comment helping me fixing the trouble faster Such a hint could look like: From now on there is a lazy and a strict variant, so import either X or Y. Or functions W has been removed, use lib K or L instead. c) The person doing the initial change (breaking things) knows most about the change and knows best how to tell people what to do.. Even if i didn't you can upload a transformation to save other peoples time.. I think this is the way to go in the long run: Create a huge database of refactorings either giving you hints how to make a package compile on a different system or maybe even applying some of them automatically. With some time this has the chance to become some "old deep" knowledge as it is burried in autotools now ? Anyway implementing this would be a lot of work put might pay of one day. Of course this applies not only to haskell systems.. Hopefully it will not result in breakages occur more often because they will become cheaper? What do you think? Sincerly Marc Weber