On 09 June 2004 20:29, S. Alexander Jacobson wrote:
The proposal should simply define the file format that Angela and Peter use to deliver Haskell packages to Wally. A Haskell package is some combiation of:
* Haskell source * binary libs for the target platform, * documentation, * data, * and meta-data
I don't think you're suggesting anything that isn't already covered by the proposal. Others have already responded to that effect, but I'll reiterate: there are several kinds of binary package which the end user can install. These include: 1. Platform-native packages: RPM, Debian, Windows MSI, etc. 2. Generic binary distribution, generated by './Setup.lhs bdist' I believe what you're asking for is (2). These binary distributions can be installed by anyone with a Haskell compiler on their system, by unpacking the distribution and invoking './Setup install'. However, I don't consider (2) to be a priority. Funcionality-wise, binary distributions are less desirable than platform-native packages, because they don't deal with installing dependencies and they don't let you uninstall the package later. When installing software, it is good practice to co-operate with the system's native packaging system. (2) is useful on systems that don't have a native packaging system, e.g. Solaris. However, on those systems, Joe User can usually just become Bob and install packages from source (it's not hard; just do './Setup.lhs configure; ./Setup.lhs build; ./Setup.lhs install'). Cheers, Simon
hello, this discussion has become rather confusing, i lost track of all the roles that were intrduced, so forgive me if i am asking an obvios question. is the following possible (and simple): i am a linux user, and i want to download and play with a haskell (binary) library (say wxHaskell). however i am at university, where i don't have root permisions, so i cannot use rpm (as it has fixed installation path). so i just want to put the library in my home directory and use it, but i don't want to have to recompile it, as this is slow and may require tools i don't have or i don't know how to use. furthermore, if i don't like the library i should be able to still delete it, and somehow inform my haskell implementation that the library is not there anymore. i have been in such situations very often (on windows machines too), and i hope that with the LIP this is not too hard to do. bye iavor Simon Marlow wrote:
On 09 June 2004 20:29, S. Alexander Jacobson wrote:
The proposal should simply define the file format that Angela and Peter use to deliver Haskell packages to Wally. A Haskell package is some combiation of:
* Haskell source * binary libs for the target platform, * documentation, * data, * and meta-data
I don't think you're suggesting anything that isn't already covered by the proposal. Others have already responded to that effect, but I'll reiterate: there are several kinds of binary package which the end user can install. These include:
1. Platform-native packages: RPM, Debian, Windows MSI, etc. 2. Generic binary distribution, generated by './Setup.lhs bdist'
I believe what you're asking for is (2). These binary distributions can be installed by anyone with a Haskell compiler on their system, by unpacking the distribution and invoking './Setup install'.
However, I don't consider (2) to be a priority. Funcionality-wise, binary distributions are less desirable than platform-native packages, because they don't deal with installing dependencies and they don't let you uninstall the package later. When installing software, it is good practice to co-operate with the system's native packaging system.
(2) is useful on systems that don't have a native packaging system, e.g. Solaris. However, on those systems, Joe User can usually just become Bob and install packages from source (it's not hard; just do './Setup.lhs configure; ./Setup.lhs build; ./Setup.lhs install').
Cheers, Simon _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
"Iavor S. Diatchki"
i am a linux user, and i want to download and play with a haskell (binary) library (say wxHaskell). however i am at university, where i don't have root permisions, so i cannot use rpm (as it has fixed installation path). so i just want to put the library in my home directory and use it, but i don't want to have to recompile it, as this is slow and may require tools i don't have or i don't know how to use. furthermore, if i don't like the library i should be able to still delete it, and somehow inform my haskell implementation that the library is not there anymore. (snip)
This is what Simon mentioned in (2):
Simon Marlow wrote:
(snip)
2. Generic binary distribution, generated by './Setup.lhs bdist'
And we do hope to support it in the near future (probably at the 1.0 release), but it's not a priority for the 0.1 release. BTW, this is somewhat tricky, since you clearly have to get someone who has your platform to build it for you, just as they have to build an RPM, so it's not clear that there will be a lot of "generic binary distribution" packages out there. Of course, this is a problem that's inherant to binary distributions, not just Cabal. GHC can actually be installed like this, btw. peace, isaac
On Mon, 14 Jun 2004, Simon Marlow wrote:
I don't think you're suggesting anything that isn't already covered by the proposal. Others have already responded to that effect, but I'll reiterate: there are several kinds of binary package which the end user can install. These include:
1. Platform-native packages: RPM, Debian, Windows MSI, etc. 2. Generic binary distribution, generated by './Setup.lhs bdist'
Ok, I'll simplify. There are only two kinds of packages; those that include platform specific binaries and those that don't. In the case of the former, I don't see what value the proposal provides over autoconf/make for the person operating the compiler (Peter Packager) or over RPM MSI etc for the person installing the package (Wally/PNW). In the case of the later, the proposal is severely deficient in requiring Roland to intermediate even in the case of code created by Angela!
However, I don't consider (2) to be a priority.
You're right, it should be subsumed in the more general case of packages with platform
(2) is useful on systems that don't have a native packaging system, e.g. Solaris. However, on those systems, Joe User can usually just become Bob and install packages from source (it's not hard; just do './Setup.lhs configure; ./Setup.lhs build; ./Setup.lhs install').
How is this superior to "./configure;make;make install"? The priority should be in dealing with code created by Angela. She should not need Peter to deliver a package to PNW/Wally. The current proposal does not serve that need at all! -Alex- PS Perhaps it makes sense to convene live in (IRC) somewhere to discuss.... _________________________________________________________________ S. Alexander Jacobson mailto:me@alexjacobson.com tel:917-770-6565 http://alexjacobson.com
S. Alexander Jacobson wrote:
How is this superior to "./configure;make;make install"?
The Cabal proposal is basically a standardised ghc-pkg. It allows a script to query installed packages and provides a regular way to register new packages. While autoconf will have to guess almost anything platform specific, e.g. library pathnames, Setup.lhs just imports a library that already knows these specifics. (Alex: Setup.lhs does not /contain/ knowledge about pathnames, it /imports/ said knowledge at install time.) Therefore, Cabal supports the scenario where Angela creates a package (her Setup.lhs is quite simple and relieves her of the platform specific annoyances) and Joe installs it (by calling Setup.lhs the same way he would otherwise call configure). That Donald Debian is also supported is almost a side effect. To package a Haskell library Donald doesn't have to write Setup.lhs (Angela already did that), he writes a control file. But since Setup.lhs already does the hard stuff, Donald doesn't actually write the control file, he just uses basically the same control file for every Haskell library. The only feature Setup.lhs has to provide for that to work is the ability to compile a package for some path and then install it into another. Support for Marcus also comes at no cost. Marcus already has his makefile; his Setup.lhs is trivial, as it simply shells out to make. The advantage over make is the ability to register the installed package with every compiler and Donald can again use his proven control file.
The priority should be in dealing with code created by Angela. She should not need Peter to deliver a package to PNW/Wally.
She doesn't. Wally has (by definition) at least one Haskell implementation. Therefore he can call Setup.lhs and get the package installed. That simple case is actually served best. But Debian users *want* the help of Donald. Though it may be quite easy to install a source package using Cabal, the convenience of just saying "apt-get install some-haskell-library" cannot be topped. Therefore Cabal is useful even for simple packages. Anyway, I like the current proposal. It's quite minimalistic, it serves a well defined purpose and has the potential to serve it well. Cabal shouldn't be repurposed before it even goes into production. Btw, I'd like to see a hmake-like library in the standard libraries or as part of Cabal. Of course, not in version 1.0 or before. Regards, Udo. -- While climbing with a guy who had a really old and worn-looking rope, I asked him how often he changed it. 'Everytime it breaks' he said.
"S. Alexander Jacobson"
On Mon, 14 Jun 2004, Simon Marlow wrote:
I don't think you're suggesting anything that isn't already covered by the proposal. Others have already responded to that effect, but I'll reiterate: there are several kinds of binary package which the end user can install. These include:
1. Platform-native packages: RPM, Debian, Windows MSI, etc. 2. Generic binary distribution, generated by './Setup.lhs bdist' (snip) In the case of the later, the proposal is severely deficient in requiring Roland to intermediate even in the case of code created by Angela!
This is not true in the least. It does _not_ require Rowland as an intermediary. Given that section 1.2 explains that Angela will distribute her code as a source package, I don't know why you believe this. Perhaps my previous email will clarify that. (snip)
The priority should be in dealing with code created by Angela.
This is not the case. This must be a fundamental misunderstanding, and I hope that you will have a little more faith once this is clarified.
She should not need Peter to deliver a package to PNW/Wally.
She doesn't need Peter/Rowland, but the consumer of Peter's packages (PNW) may prefer to use packages (I know I do!) so we are happy to support this need. Note that such packages are distinct from generic binary distributions.
The current proposal does not serve that need at all!
I assert that it does.
PS Perhaps it makes sense to convene live in (IRC) somewhere to discuss....
Sure! Maybe we can get some of the confusion cleared up and you can make some concrete suggestions for the document. I hang out on #haskell on irc.freenode.net. I'm SyntaxNinja or SyntaxLaptop. peace, isaac
participants (5)
-
Iavor S. Diatchki -
Isaac Jones -
S. Alexander Jacobson -
Simon Marlow -
Udo Stenzel