I'm considering packaging several Haskell libraries for Debian, and wonder what people think about where things should go. Please excuse me if anyone feels that this email isn't appropriate for this mailing list. Though these are somewhat Debian-specific questions, I thought that some Haskell folks could lent their insight. You would be the users after all. There aren't many examples of libraries (without any binaries) that are packaged thus far. I noticed that ctklight installs stuff in /usr/share/hugs98/extentions, but it can be used with GHC also, so I am not sure why its done this way. I don't use hugs too much though, also I don't know anything about nhc. So I'm considering sticking the *.lhs files for HUnit, for example, in /usr/share/hunit. Then people can alter their Makefiles to include that directory in either hugs or ghc, but I see one problem with that: GHC would want to compile the source files, and stick them in /usr/share/hunit, but would be unable to (because of permissions problems when users compile). The package could install binary files, but then it would build-depend on ghc which doesn't exist for several Debian platforms. So I guess it could check to see if ghc is installed on the building computer and stick binaries in /usr/lib. Another option would be to compile packages for GHC in the post-install script if ghc is installed, and stick those installed files in /usr/lib, and the .hs files in /usr/share/hugs98/extentions if hugs is installed. So my question is: if you were / are using Debian, what do you think that a well-behaved Haskell library package should do? Also Debian users might email me privately with suggestions on what are the most important programs to package: I plan to start with the ones I use the most. peace, Isaac
...
So I'm considering sticking the *.lhs files for HUnit, for example, in /usr/share/hunit. Then people can alter their Makefiles to include that directory in either hugs or ghc, but I see one problem with that: GHC would want to compile the source files, and stick them in /usr/share/hunit, but would be unable to (because of permissions problems when users compile).
Yes, it does seem that you'd want the libraries to be installed in binary form for ghc (and probably if it supports it, nhc). Among other things, libraries should be compiled with as much optimization as possible, while the user may not want to do the same with his code (which he has to repeatedly recompile).
The package could install binary files, but then it would build-depend on ghc which doesn't exist for several Debian platforms. So I guess it could check to see if ghc is installed on the building computer and stick binaries in /usr/lib.
This would create problems with buildd's would it not, since if you don't build-depend on ghc, it won't be installed on the building computers?
Another option would be to compile packages for GHC in the post-install script if ghc is installed, and stick those installed files in /usr/lib, and the .hs files in /usr/share/hugs98/extentions if hugs is installed.
I vote for this. The only hairy issue is that this would mean that the order of installation of packages would be important, which does not sound like a good idea at all. :( It seems that things might be optimal if there were some sort of registry system, where the library packages could "inform" the compilers that they have packages available and the compilers could complete the installation themselves. I think that the emacsen do something like this. If I had to implement it, I'd stick all the libraries in /usr/share/haskell-src or something, and then have all the compilers (at least ghc and hugs) provide a "install libraries" script which would look in that directory and install (either by compiling, symlinking or copying) the libraries in the right place. This script would be called both in the postinst and the postrm (to remove the compiled libraries) of all libraries and also the compilers. Of course, this assumes you can get the hugs and ghc maintainers to agree on the system. Although even if just ghc does it, it will at least solve the problems wrt order of installation. -- David Roundy http://civet.berkeley.edu/droundy/
On Thu, Dec 12, 2002 at 11:36:59AM -0500, haskell-cafe-admin@haskell.org wrote:
The package could install binary files, but then it would build-depend on ghc which doesn't exist for several Debian platforms. So I guess it could check to see if ghc is installed on the building computer and stick binaries in /usr/lib.
You can have architecture-specific build dependencies, like this: Build-Depends: ghc [i386], debhelper You could build with ghc on exactly the platforms where it is available, though you'd have to maintain that list of platforms by hand.
Another option would be to compile packages for GHC in the post-install script if ghc is installed, and stick those installed files in /usr/lib, and the .hs files in /usr/share/hugs98/extentions if hugs is installed.
I don't like this. It tends to get complicated fast, it's fragile, and it's not nice when installing or removing packages. I'm always annoyed when the emacs packages do this. Since we only have to support two Haskell compilers, I think it's reasonable to just provide object code for both of them. (It's different for emacsen, where there are lots of incompatible flavours, and maintainers aren't expected to have all of them installed.) Richard Braakman
participants (3)
-
David Roundy -
None -
Richard Braakman