new Library Infrastructure spec.
S. Alexander Jacobson
haskell at alexjacobson.com
Mon Jun 14 14:50:29 EDT 2004
On Wed, 9 Jun 2004, Isaac Jones wrote:
> > 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
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
(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
In scenario 2, I don't see why we need anything
more complex than a file format.
> > 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!)
> 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
> 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
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
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?
S. Alexander Jacobson mailto:me at alexjacobson.com
More information about the Libraries