I'd like to propose a refactoring of the package description, as follows: (1) The unprocessed source tree of every package would contain a package description, consisting a single stanza: name: unique name of the package (compulsory) version: package version number (compulsory) license: identifier for a common license (compulsory) license-file: name of a file containing the license copyright: copyright holder (compulsory) author: original author of the package maintainer: current maintainer of the package (if different) stability: stability level homepage: URL of the package homepage package-url: (same as homepage?) description: free-text description of the package category: from a list to be specified tested-with: list of compilers and versions (?) build-depends: list of packages needed to build this one exposed-modules: list of modules added by this package executables: list of programs added by this package (2) Packages using the simple build infrastructure would optionally provide an additional file of build parameters for that infrastructure, consisting of a basic stanza and zero or more executable stanzas: build-package: Boolean: is package buildable? (default: True) <buildinfo> (for library, if any) executable: name of a program from executables main-is: relative filename for the main module <buildinfo> (for the executable) where <buildinfo> consists of: other-modules: list of additional modules hs-source-dir: name of root directory of the module hierarchy extensions: list of Haskell extensions used by every module options-ghc: additional options for GHC options-hugs: additional options for Hugs options-nhc: additional options for NHC c-sources: list of C source files cc-options: options for the C compiler includes: header files describing foreign imports include-dirs: directories to search for header files ld-options: options for the linker extra-libs: extra libraries to link with extra-lib-dirs: directories to search for libraries frameworks: list of Darwin/MacOS X frameworks to link to (The options fields are inconsistent -- we can sort that out later.) This file need not be present until after the pre-conf step; in some cases it will be generated from a template by that step.