new Library Infrastructure spec.

[Isaac Jones]

"S. Alexander Jacobson" <haskell at alexjacobson.com> writes:

> On Wed, 2 Jun 2004, Isaac Jones wrote:
>> Here are some more issues you're scheme will have to deal with:
>>
>> 1) Marcus Makefile.  He's important to us; he's a hard-core haskell
>>    developer and we want to support him.  How does he go about calling
>>    through to the "make install" command?
>
> I thought this proposal was an alternative to
> "make install."  Are people doing things with
> makefiles that can't be done using StaticSetup?

Please see

(Section 1.1):

  Marcus Makefile is like Angela, but more sophisticated. He has a
  complicated tool, and uses makefiles. Still, he wants to arrange
  that Roland, Donald, Bob, Sam, and Joe don't need to know about his
  internal complexity.

(Chapter 4): where the interface for the Setup script is explained.

(Section 5.4)

  The Haskell libraries that support the simple build infrastructure
  can, of course, also be re-used to make setup scripts that work
  quite differently. At one extreme is a setup script that immediately
  shells out into make, which does all the work.

It's important to remember that the Setup script is an _interface_
that hides underlying complexity.  Under the hood might be
Distribution.Simple (section 5.3), or it might be a bunch of
makefiles, or it might be hmake, or it might be a haskell program that
you write yourself.

We're trying to give the end users (and tools that may be layered on
top of the packaging system) a consistent interface to packages whose
needs and underlying implementations are very different.  (Think of
the different kinds of needs between HUnit and wxHaskell).

Now Distribution.Simple is a particular implementation of this
interface which is meant for very simple libraries and tools.

What you propose to provide is a secure infrastructure for building
and installing very simple libraries and tools, but not providing a
common interface across diverse libraries and tools.  I feel that this
is a completely different goal.  (I also think that if this is what's
desired, the user is better off using a packaging system that has more
guarantees, and not installing code from untrusted sources at all (see
my work in "apt-secure" btw) but that's neither here nor there.)

>> 2) If you allow executables to be installed, you'll have to watch out
>>    for attacks which replace "ls" or something.  I guess you could
>>    have a warning for any package which tries to overwrite an existing
>>    file, though this may happen a lot for upgrading a current library.
>
> But typically it would happen all within the same
> directory so there it should be possible to offer
> the user the option to accept all updates to a
> particular directory.
>
> Simply telling the user in which directories
> updates may be happening is a big plus.

That's a good point.

>> 3) There is some grey area between the Angela and Marcus use cases
>>    where she can perform extra preprocessing steps and configuration
>>    steps within the context of Setup.lhs (since she has all of Haskell
>>    at her disposal.)  In your scheme, there is no space between Angela
>>    and Marcus. You're either in or out when it comes to utilizing
>>    Distribution.Simple.
>
> I'm not sure I follow here.  Nothing stops you
> from chaining/recursive StaticSetup...

I don't know what you mean by recursive StaticSetup, so I'll try
again.

Distribution.Simple provides some mechanisms for making Angela's life
easier, especially with very simple libraries.  Now say Angela has a
library that uses Distribution.Simple, but she's altered it to utilize
the Happy preprocessor, and (let's say) Distribution.Simple doesn't
know anything about Happy.  Now Angela can add a "system" call to her
Setup file to preprocess what she needs to, and continue using the
rest of the Distribution.Simple mechanism she was using before.

In the StaticSetup scheme, Angela is out of luck.  She can't change
the behavior of StaticSetup to do the right thing, so she has to get
rid of her build system altogether and start from scratch with
makefiles or something.  This is what we want to avoid.


peace,

  isaac