On Wed, Sep 29, 2004 at 07:48:20PM -0500, John Goerzen wrote:

I have several questions:

1. Section 3.4 says built libraries should go in

/usr/lib/haskell-libraries/compiler/package/, though I can't find even one single package in Debian that is actually there. Is this path really recommended?

We don't really have any libraries to speak of in Debian, bar those that come as part of the compilers. The policy is designed to try to get things to be consistent from when they go in, rather than having to try to fix everything up later; package names are an example of where this is particularly important.

I think it would be nice to have them all in a central place so you can use things like ghc --show-iface on the interface files (although this won't work for libraries that come with the compiler. Or perhaps we should use symlinks to have them appear there - maybe symlinks for everything would make sense, come to that? Or maybe we should just forget it and have dpkg -L be an extra layer of indirection when you want to find things?)

Back on package names, I think a reasonable compromise is libghc{5,6}-foo-dev libnhc98-foo-dev libhugs-foo with libghc6foo being used for .so libraries if/when they appear.

The reason it's a compromise is that the ghci libraries will then be in a -dev package, although in theory they could be used in the same way as hugs' libraries. However, I don't think anyone will want to do this, so in the absence of cabal (http://www.haskell.org/cabal/) making it easy to have the ghc and ghci libraries separated in this way I think we should just go with the above.

2. Regarding the strict dependencies in 3.2, does this apply even if

the library is built without any -O options?

According to a quick test it doesn't apply if it's never been built with optimisation either, but I couldn't swear to this being true in all cases. I'll try to get a definitive answer from Simon M on this.

This would be against Debian policy 10.1 though:

By default, when a package is being built, any binaries created should include debugging information, as well as being compiled with optimization.

Also, I think optimisation is probably even more important for Haskell than for C etc. as I imagine it can have a massive impact on space usage. (I'm guessing here really, though).

3. Regarding /usr/lib/compiler/debian-dependencies mentioned in 3.2,

this also does not exist in any existing package in sid. Where should this information come from?

This doesn't exist yet (and won't for ghc in sid at least until the current packages gets into testing). This seems like as good a time as any to talk about my further thoughts on this.

When a new ghc6 comes out (for example) we want to somehow magically update the ghc6 build-deps, but we'd prefer not to remove any mention of ghc6 that is also in the control file. The obvious solution is to have a control.in from which control is generated, but we don't want this to happen every time the package is built (it won't help in the cases where the deps have changed because the build process will already have thrown a wobbly by the time it gets run, and when they haven't changed it might mean changes accidentally made by people to control get lost). So I propose

/usr/lib/compiler/debian-dependencies contains something like: ghc6=ghc6 [i386 ia64 sparc alpha s390 hppa powerpc] (>= 6.2.1), ghc6 [i386 ia64 sparc alpha s390 hppa powerpc] (<< 6.2.1+) (wrapped for readability)

haskell_update_control is run by hand and does something roughly equivalent to sed "s/$ghc6/.../" < debian/control.in > debian/control

and in appropriate targets in debian/rules we run haskell_update_control --check or somesuch which checks that debian/control wouldn't be changed if it were run (and fails if it would).

nhc and hugs can probably be much less strict, althogh I haven't actually checked nhc yet. One worry I have is the way the FFI is done may change over time.

Any comments on any of the above welcomed!

Thanks Ian