Re: how to package Haskell libraries
On Sun, Jun 22, 2003 at 09:07:05PM -0400, Colin Walters wrote: Right, but that approach definitely has some disadvantages, namely fragility and the fact that we're kind of subverting the whole idea of binary packages. It kind of depends on what Haskell library means. Is it more like a C library (potentially complex build system, dependencies, etc) or is it more like a Perl module? Nobody in their sane mind would propose to build XS modules on the user's system, but Python folks seems to be happy about having their pyc and pyo files generated in the postinst. Marcelo
Re: how to package Haskell libraries
On Mon, Jun 23, 2003 at 10:38:40AM +0200, Marcelo E. Magallon wrote: On Sun, Jun 22, 2003 at 09:07:05PM -0400, Colin Walters wrote: Right, but that approach definitely has some disadvantages, namely fragility and the fact that we're kind of subverting the whole idea of binary packages. It kind of depends on what Haskell library means. Is it more like a C library (potentially complex build system, dependencies, etc) or is it more like a Perl module? I think the problem is that it could vary, and probably there needs to be at least support for binary haskell libraries. Certainly any library that is pure haskell probably will have a pretty simple build system. But a lot of interesting haskell libraries would involve bindings to other libraries, so installing them on the users' machine would require dev versions of those libraries, which would be annoying to an end user... on the other hand, as far as I know haskell doesn't support dynamic linking, which would mean that the library packages would themselves be -dev packages, and dependency (as opposed to just build-dependency) on -dev packages would be normal. On consideration, I think I'd vote for the build binaries at install time approach. The only problem with it is that it may take an awful lot of time to do so. But as long as haskell developers (or people compiling a haskell package from source) are the only ones to suffer from this wait, it seems like a good tradeoff. If we require a separate package for each compiler, I imagine many library packagers would opt for just packaging their library for ghc, which would be a shame as far as portability goes. -- David Roundy http://www.abridgegame.org
Re: how to package Haskell libraries
Marcelo E. Magallon [EMAIL PROTECTED] writes: It kind of depends on what Haskell library means. Is it more like a C library (potentially complex build system, dependencies, etc) or is it more like a Perl module? As David Roundy sorta indicated, it could be either one. Building Haskell stuff can be pretty complex. There are a number of preprocessors and lots of useful libraries wrap stuff like the X11 library. WRT fragility, I would be afraid that, when building on the end user's machine, one out-of-date tool or library on the machine will hose a whole set of applications (this is a problem either way). I hate to say it, but it doesn't seem like the Haskell/Debian community will necessarily do a good job keeping packages up-to-date. It is true that the slowness of building on the user's machine would probably only be incurred by the developers, and this can't be worse than the situation we have now where we have to build everything by hand and put it in /usr/local. David Roundy: If we require a separate package for each compiler, I imagine many library packagers would opt for just packaging their library for ghc, which would be a shame as far as portability goes. Indeed. Another problem is that all packages which work for a particular compiler will have to be updated at the same time as the compiler. In either case, we're going to have to build some software support, either a system to build rebuild packages on the end-user's machine, or I can immagine a system that would help a packager build different binary packages for the various compilers, but it will still take some coordination to get packages updated at the same time. peace, isaac
Re: how to package Haskell libraries
On Mon, 2003-06-23 at 04:38, Marcelo E. Magallon wrote: On Sun, Jun 22, 2003 at 09:07:05PM -0400, Colin Walters wrote: Right, but that approach definitely has some disadvantages, namely fragility and the fact that we're kind of subverting the whole idea of binary packages. It kind of depends on what Haskell library means. Is it more like a C library (potentially complex build system, dependencies, etc) or is it more like a Perl module? Probably somewhere in between. Nobody in their sane mind would propose to build XS modules on the user's system, but Python folks seems to be happy about having their pyc and pyo files generated in the postinst. Python is different because 1) Python programs will still work even if the byte-compilation fails. Python just looks for .pyo first, and falls back to interpreting .py. 2) There's only one Python implementation, so random Python code is fairly likely to work with it :)
Re: how to package Haskell libraries
On Mon, Jun 23, 2003 at 12:32:36PM -0400, Colin Walters wrote: so random Python code is fairly likely to work with it :) You are thinking about Perl. Random Python code is likely to fail to compile. ;-) -m.
Re: how to package Haskell libraries
On Sunday 22 June 2003 19:45, Isaac Jones wrote: There has been a lot of discussion recently on the Haskell mailing lists about the best ways to package Haskell libraries and tools for Debian. The main issues are: 1) there are a variety of compiler implementations, one of which is an interpreter :) 2) not all Haskell implementations are available on all architectures (ghc for instance) 3) just about every Haskell compiler and release is binary-incompatible, (except maybe for nhc98). You might be able to apply the same techniques applied to C++ libs which suffer the same ABI-incompatibility. Currently, the workaround is to postfix the libs with a string-tag for the compiler-ABI. Hmmm, I just wonder: is it true that there is no solution for supporting different ABIs but rather just a transition-plan ? An imho real fix (afaik) encompasses an extension to the ELF-format/dynamic linker and is not due in the near future. Uli
Re: how to package Haskell libraries
Isaac Jones [EMAIL PROTECTED] writes: How would Debian prefer to see this? Some people tell me that it'll probably be too slow to build the packages on the end-user's system (as is done for elisp), That's also done with Common Lisp, and I don't think it's too slow (as an end-user). -- Alan Shutko [EMAIL PROTECTED] - I am the rocks. Looking for a developer in St. Louis? http://web.springies.com/~ats/ Put your cat in box, add postage and mark Schr*edinger.
Re: how to package Haskell libraries
On Sun, 2003-06-22 at 18:08, Alan Shutko wrote: Isaac Jones [EMAIL PROTECTED] writes: How would Debian prefer to see this? Some people tell me that it'll probably be too slow to build the packages on the end-user's system (as is done for elisp), That's also done with Common Lisp, and I don't think it's too slow (as an end-user). Right, but that approach definitely has some disadvantages, namely fragility and the fact that we're kind of subverting the whole idea of binary packages.
