"S. Alexander Jacobson"
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