
On Wed, 9 Jun 2004, Malcolm Wallace wrote:
You are almost certainly Joe, if your ideal world is to download a .msi InstallShield binary package and press the button.
I'm not Joe. According to the proposal: Joe User is simply a Haskell user. He does not download new packages. I'm not Bob or Sam either: Bob the Builder and Sam Sysadmin both download, build, and install new packages. The only difference between the two is that Sam has root permission, and can install packages in more globally-visible places. I do have "root" permission on my windows laptop and occasionaly install stuff in more "globally-visible places" but, since I haven't bothered to get the cygwin toolchain working properly to produce DLLs and my C is really really rusty , I don't really *build* new packages. Let's have two new roles: Wally Windows and Peter Packager. Wally installs but does not necessarily build. Peter builds but does not necessarily install. 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 Wally's local Haskell interpreter/compiler should know how to unpack a Haskell Package and install/register its component files in the appropriate places on his system with minimal fuss. Angela's local Haskell interpreter/compiler should make it easy for her to create a Haskell Package if it doesn't have any binaries (or she already has the binaries she needs and is targetting a particular platform). Marcus and Peter can use Autoconf/Make or whatever they want to build the packages from C (or whatever source). There is no reason that the packaging system needs to invoke autoconf/make (especially given that we can't assume Wally actually has autoconf/make!) Similarly, if installation involves other sorts of files (e.g. installing autoconf/make), Peter can use RPM .msi etc. to do that job, perhaps invoking the Haskell packaging system from there. The packaging system does not need a way to invoke RPM etc. This thing should be super-simple; a package file format together with a meta-data format telling an installer how to handle package contents. -Alex- _________________________________________________________________ S. Alexander Jacobson mailto:me@alexjacobson.com tel:917-770-6565 http://alexjacobson.com
"S. Alexander Jacobson"
writes: There are e.g. Win32 installers HDirect and HaskellScript. Who produced them and who is intended to use them?
Bob the Builder produced them. Joe User uses them.
But you are right, there is indeed an intermediate role, the person who downloads and installs the binary package. This does not necessarily involve any building, but still requires a minor degree of knowledge of the packaging scheme.
However, in Cabal, there are many different possible binary packaging schemes. Various people will use RPM, .deb, .msi, apt-get, BSD ports, and so on. Essentially, we assume that the person who downloads and installs one of these formats is competent with their chosen mechanism. They just use whatever is standard for their platform. So it seems fair to characterise that role as Joe User, since we don't really expect any familiarity with Cabal. Indeed, such a person does not (knowingly) use Cabal at all!
However Cabal does address the person who /creates/ an RPM, .msi, etc, who needs have a documented protocol for building, installing, and registering Haskell code. Roland, Willie, etc, embed that knowledge into the binary package, so the final user, Joe, does not need to think about it.
I run GHC on my Windows box and can't easily/reliably get C code to compile and produce DLLs (both because my C is *very* rusty and because I don't have an up-to-date version of all the cygwin mingwin blah blah packages). Yet, I do occasionally download and install Haskell libraries? Am I Bob, Peter, Sam, Joe, or perhaps someone new?
You are almost certainly Joe, if your ideal world is to download a .msi InstallShield binary package and press the button.
Regards, Malcolm _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries