If we want to add debugging support consider a packagetree like this: a - b ( depends on b and c, c on d and e) | + - c - d | + - e its obvious if I want to have a profiling lib a I need b..e compiled with -prof, too But if I want to build it with debugging messages what about b,c,d,e They might have been compiled with debugging support but don't have to. Consider the scenario a,c,d beeing compiled as debugging, but I'm also working on another project which doesn't need c as debugging. This would mean I need two versions of c (with debugging enabled and disabled) -> naming conflict.. This could be solved by introducing aliases. eg ./cabal-install d as d-debug --enable-debug ./cabal-install c as c-debug --enable-debug --with d-debug as d ./cabal-install a --with c-debug as c and I would be done This way you can even install different developement versions of your libraries .. (sure testing should be done with HUnit or qpuickcheck not with final applications ..) Of course this is only useful for testing not for distribution ... I don't think this would make things much more complicated but would make the system much more flexible .. Wait.. This would mean: you have a package id and you have flags to select the right version a flag is a) version b) configure options such as profile, debug, use lib a instead of b, ... But this would mean when deciding which libraries to install by default: instance Default Stability -- stable wins instance Default Version -- greater wins instance Default Debug -- no debug wins instance Default Profiling -- no profiling wins if not specified else. This leads me to the question: Is it enough to identify a package by (name/id) and version? I think a more dimensional way would be useful Thus adding another dimension (os / instance Default Cross-Compilation-Target -- defaults to no cross-compilation an easy extension.. And this would make it easy to manage libs for your os, that of your neighbour, your microcontroller, .... Of course ghc-pkg list will no longer show Lib (version=2.0, debug=on, profiling=on, target-architecture=x64) rather than Lib-2.0 Some of those flags would be backtracking (architecture, profiling) others not (debug = on) Fortunately you don't have the design of ghc to test this as you can use aliases .. Any comments? Is this all nonsense ? Marc