LIP/cabal

[Ian Lynagh]

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