The example in 1.2 is still a bit mysterious to me. Initially Angela has the following files: ./Data/Set.hs ./Data/Bag.hs ./Angela/Internals.hs then she runs ./Setup.lhs configure --ghc I assume she now has the above files plus ./.Setup-info or somesuch on Unixish OSes, and a hidden file on Windows? ./Setup.lhs build She now has the previous 4 files plus the following? ./Data/Set.o ./Data/Bag.o ./Angela/Internals.o How did that happen? Did it just compile all .hs/.lhs files it found inside .? Did it work out what order to compile them in a la ghc --make? ./Setup.lhs src-dist Presumably angela-coll-1.tar.gz now contains the 3 .hs files? Again, did it just pick out any and all .hs/.lhs files inside .? Is Data/Set.hs or angela-coll-1/Data/Set.hs in the tarball? Also, you haven't actually told cabal Angela.Internals is internal, as mentioned in the text, right? ----- 2.2 says "one or more packages (of which the Prelude is one)". Did you really mean this, i.e. that there is a package Prelude containing the module Prelude? ----- In 3.1.2: Suppose I have A-2.1 installed. I install B-1.0 and my whizzy installing whatsit goes off and grabs A-1.9 for me. I now have 1.9 as the exposed A? I'm sure that's not what I wanted, especially as one of my programs won't work without that bugfix in A-2.0. Three alternatives spring to mind: If A is installed it is exposed if it is the newest version of A only. If A is installed it is exposed if it is the newest version of A *and* the second newest version of A was exposed before. Packages have a manual and automatic mode. In automatic mode we behave like the first option. In manual mode the exposed version is not changed. (this is what Debian's update-alternatives does). There is also the issue of unregistering packages. If an exposed package is unregistered then you could either fall back to the newest installed version or leave everything unexposed. In the third choice above, falling back to the newest and setting it to automatic if it isn't already makes most sense I think (and is what update-alternatives does I believe). Checking the update-alternatives logic if you go that route would be sensible - I am not an expert on it, but have a feeling it has a bit more complexity than I've described to cope with various scenarios in teh best way possible. ----- 3.2 says: When all the -package and -hide-package flags on the compiler's command line have been processed, the resulting module namespace must not contain any overlapping modules; the compiler should check this and report any errors. System packages are implicitly shadowed by user packages of the same name so their modules don't count for this check, right? Are modules in my program allowed to overlap with those of packages? What about modules in user packages overlapping with (non-shadowed) modules in system packages? Also, this isn't going to guarantee no overlaps, e.g. with the As and Bs from 3.1.2, right? A-1.9 could have a module X, A-2.1 not have a module X and package C also have a module X, with A-2.1, B, C exposed. Oh, suppose B-1.0 from earlier is a system package that depends on A-1.9. There is an A-1.9 as one of my user packages, and also as a global package. Presumably it, and thus the rest of my program, uses the global A-1.9? ----- 4.1: In the discussion about quotes and skipping fields, with this sort of format I'd expect a line starting with a non-comment/whitespace character to start a new field. Also, if cabal can't understand my deps line I'd expect it to tell me it doesn't know what to do, but I think I might be missing the point there. ----- 4.2 I think [install-prefix] shouldn't be there but --install-prefix should be used instead. Why can't we have an uninstall that normally just fails? That's exactly the same as "make uninstall", after all. (I don't actually really care about this, just curious. It seems silly not to support uninstall for those people who take the trouble to write one in their Makefiles). ----- 4.3 With my Debian hat on I think, in the package building script for A, I want to do: ./Setup.lhs clean # # the Debian tools will make the diff for the Debian source package # here # ./Setup.lhs configure --with-compiler=/usr/bin/ghc6 \ --prefix=/usr/lib/ghc6/modules/A ./Setup.lhs build ./Setup.lhs install --user \ --install-prefix=`pwd`/debian/libhaskell-ghc6-A/usr/lib/ghc6/modules/A mv installed-pkg-descr debian/libhaskell-ghc6-A/usr/lib/ghc6/modules/A # # ./Setup.lhs clean ./Setup.lhs configure --with-compiler=/usr/bin/nhc98 \ --prefix=/usr/lib/nhc98/modules/A ./Setup.lhs build ./Setup.lhs install --user \ --install-prefix=`pwd`/debian/libhaskell-nhc98-A/usr/lib/nhc98/modules/A mv installed-pkg-descr debian/libhaskell-nhc98-A/usr/lib/ghc6/modules/A # # Repeat for hugs, ghc5, anything else, as desired but you haven't given me a "./Setup.lhs clean". Is that just an oversight? Is there anything I've got wrong? In the postinst/prerm I'll also want to run ./Setup.lhs (un)register, pointing it at the file I copied for the first case. However, I don't think I have a Setup.lhs any more. I think I want "./Setup.lhs install" to take an additional argument --setup-prefix=`pwd`/debian/libhaskell-ghc6-A/usr/lib/ghc6/module-setup/A as I imagine this could require multiple files and different behaviour for different compilers? I'd then expect /usr/lib/ghc6/module-setup/A/Setup.lhs --register --global \ < /usr/lib/ghc6/modules/A/installed-pkg-descr to register the library (after the deb has been installed). In fact, scratch that. Get rid of the mv lines above and /usr/lib/ghc6/module-setup/A/Setup.lhs --register --global should just do it all for me. ----- Sorry if any of the above has been discussed before and I missed it. Thanks for your good work Ian