On Wed, 9 Jun 2004, Isaac Jones wrote:
(snip)
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.
What's the difference between your "Peter" and our Rowland, Donald, and Willie?
Not much. I just wanted the ability to refer generically to the packager role. "Roland et al" is both less efficient and less precise. Also, I disagree with "They [Roland et al] do this as a service for Angela Author and the community." 1. Peter does this as a service for users of the platforms his packages target not for Angela or Marcus (it could be a disservice to A&M if they didn't want their packages distributed!) 2. Contrary to the proposal, those users should NOT need Peter's services to install Angela's pure haskell packages (the 99% case). 3. Those users DO need Peter to install Marcus's packages as they require platform specific compilers etc. that those users may not have. (the 1% case but of very valuable stuff)
Also, your Wally Windows is confusingly similar to our Willie Windows, so let's please not use that name. I'll refer to him as PNW (Please, Not Wally). There is a role we haven't mentioned: the consumer of Rowland, etc., packages. They install packages for Joe (who might be themselves). They do this in a platform-dependent way that is outside our system: using dpkg, rpm, whatever (is that what you mean by your PNW?)
I used Wally as a name because I had forgotten entirely that you had a Willie. (I think your Willie is mentioned only once in the entire document.) In my first draft of that mail I actually used Joe because I don't believe Joe (as described in the document) makes any sense. We care only about people involved in the package creation -> installation process. We need only to talk about Wally/PNW. Malcolm's confusion of Joe with your PNW earlier in this thread validates this assertion. In any case, it seems much more important to flesh out the end-users experience and in particular the Windows end-user experience as it is probably the most common (and perhaps majority) case.
The reason that case is not included in this proposal is that it's outside the system as it stands now.
Yup. That is our disagreement. You are laundering in that user by wanting to wrap .rpm w/ setup.lhs. My claim is that there are only two scenarios: (1) Marcus -> Peter -> Wally/PNW (2) Angela -> Wally/PNW In scenario 1, I don't see what value the proposal adds over that provided by make/autoconf for Marcus -> Peter and InstallShielf for Peter->Wally/PNW. In scenario 2, I don't see why we need anything more complex than a file format.
(snip)
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!) (snip)
All you're saying here is that your scheme doesn't support Marcus. I'm still waiting to hear why he's not important.
No. I'm saying that YOUR scheme doesn't really support Marcus. Or, more particularly, I'm saying that I don't see the value your scheme provides over autoconf/make -- especially given the assumption that Peter knows little or nothing about Haskell.
This character (please, not Wally) can't install Marcus's package whatsoever. He's in no better or worse shape than before. For packages that "PNW" can install, our system still supports him.
But you can help Peter by giving him a simple interface that RPM or Installshield or whatever can use to install the Haskell specific components! If Peter knows little about Haskell, it makes little sense to force him to write a Setup.lhs that calls InstallShield.
It's silly to pretend that our system is leaving "PNW" in the cold. Your system certainly doesn't support "PNW" in the case of a package by Marcus. Either "PNW" is SOL, or he has to get Willie's help.
My complaint is that your system requires too much of the delivery of packages from Angela to PNW without adding value to any other scenario.
The compiler's role in installing packages is orthogonal. I don't know if you can talk the compiler authors into altering the compilers to be aware of the packaging system. I don't think such vertical integration is a good idea, personally, but they can decide that.
The proposal already makes demands on compiler authors and the proposal is for a mechanism to support mucking about in the files on which the compiler relies. How does the setup.lhs author know in which directory to put library files? Alternatively, how much knowledge of the compiler and library file hierarchy are you requiring of PNW? The document describes this workflow: ./Setup.lhs configure --ghc ./Setup.lhs build ./Setup.lhs install So this means that Angela needs to know how to install her package for GHC? and NHC? Is GHC consistent enough on different OSs such that she does not actually have to do --ghc-WinXP and --ghc-OSX? If GHC is supposed to be consistent, then you are already making substantial requirements of compilers or you are committing to maintain an up-to-date database of compiler configurations.... What happens if I've customized my local config substantially? -Alex- _________________________________________________________________ S. Alexander Jacobson mailto:me@alexjacobson.com tel:917-770-6565 http://alexjacobson.com