
On Tue, Aug 4, 2009 at 11:05 PM, Max Rabkin
On Tue, Aug 4, 2009 at 11:56 PM, Magnus Therning
wrote: AIUI, on systems with working package managers, HP will be a metapackage which depends on the appropriate "real" packages.
Yes, but again, the role of HP shouldn't be to limit the pain of installing bindings to C libraries. What I'm saying is that it's a worthwhile goal to limit that pain, but it should be handled outside of HP.
How could one do that? On systems with package managers, the platform won't bundle C libraries, but depend on them (this is correct: if software does in fact depend on a C library, it should declare that dependency). On systems without package managers, we could provide some form of "sub-platform" containing C libraries or a system for installing them, but then installing a Haskell system is no longer a one-step process.
Well, I'd hope that the stuff that's being built around _building_ HP (helper scripts / procedures for putting together binary installers on Mac and Win) is general enough so that it can be used to do a HP+ (or a number of installers) that includes different C lib bindings. In essence, that would result in a set of prepared Haskell packages for the platforms that lack a good package manager.
It's been a while since I was a regular Windows user, but it seemed then that bundling dependencies was the most common (only?) solution.
I don't know of any other way either. I just strongly oppose the idea that HP should take on the role of providing C lib bindings just because on some platforms it's hard to satisfy the C dependencies. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus@therning.org http://therning.org/magnus identi.ca|twitter: magthe