Hi, On Mon, Nov 08, 2010 at 06:58:52PM +0000, Duncan Coutts wrote:

...

...

http://trac.haskell.org/haskell-platform/wiki/AddingPackages#PackageRequirem...

Well, the policy can be changed if necessary (not that I'm proposing that here). While packages may need to be present to build an application in the platform, they don't necessarily need to be exposed as part of the platform.

That's true for binary packaging systems. It would not be true for source based ones e.g. gentoo, freebsd ports, macports or indeed someone starting with just ghc and using cabal to install the platform meta-package.

On the other hand, on those systems people would get all packages (libraries and programs) required by the Haskell platform, plus some additional ones. Wouldn't hurt too much, IMHO (allthough it feels a little bit wrong if the platform would contain programs that can't be built with only the platform). As I'm doing OpenBSD stuff, where things are a little bit different (we have a ports tree for building stuff from sources, *but* we also provide binary packages and recommend and expect ordinary users to use those): if OpenBSD would provide meta-packages (which it doesn't do yet), there would be a meta-package `haskell-platform' which run- and lib-dependencies on all the nice stuff required by the platform, and at the same time build-depends on stuff only required for *building* the platform. But I readlly don't know what would happen wrt shared libraries (which are supported now in GHC on most archs, AFAIK). Ciao, Kili

On Mon, Nov 8, 2010 at 7:46 PM, Matthias Kilian wrote:

Hi,

...

...

...

http://trac.haskell.org/haskell-platform/wiki/AddingPackages#PackageRequirem...

Well, the policy can be changed if necessary (not that I'm proposing

...

...

here). While packages may need to be present to build an application in the platform, they don't necessarily need to be exposed as part of the

On Mon, Nov 08, 2010 at 06:58:52PM +0000, Duncan Coutts wrote: that platform.

...

That's true for binary packaging systems. It would not be true for source based ones e.g. gentoo, freebsd ports, macports or indeed someone starting with just ghc and using cabal to install the platform meta-package.

On the other hand, on those systems people would get all packages (libraries and programs) required by the Haskell platform, plus some additional ones. Wouldn't hurt too much, IMHO (allthough it feels a little bit wrong if the platform would contain programs that can't be built with only the platform).

I think this was exactly the situation rationale 8.5 means to avoid. I do think it would be technically possible to make this work, but only by greatly increasing the maintenance cost for HP (I underestimated this cost originally). It's probably not a good trade-off. If cabal supported something like run-time-specified repos it would be much simpler. John

On Tue, Nov 9, 2010 at 5:12 PM, Duncan Coutts wrote:

On 9 November 2010 10:40, John Lato wrote:

...

...

On the other hand, on those systems people would get all packages (libraries and programs) required by the Haskell platform, plus some additional ones. Wouldn't hurt too much, IMHO (allthough it feels a little bit wrong if the platform would contain programs that can't be built with only the platform).

I think this was exactly the situation rationale 8.5 means to avoid. I do think it would be technically possible to make this work, but only by greatly increasing the maintenance cost for HP (I underestimated this cost originally). It's probably not a good trade-off.

...

If cabal supported something like run-time-specified repos it would be much simpler.

What sort of thing are you thinking of here?

If, in addition to the global and user package stores, you could specify alternate package stores. Then it would be possible to do e.g. cabal install --use-package-store=./buildlibs to create a package store at ./buildlibs (if it doesn't exist) and install a library there. Then later commands could do cabal install --extra-package-store=./buildlibs to check for packages in that extra location in addition to the default global and user locations. This would certainly enable building non-blessed libs as part of the HP and differentiating from the normal blessed packages. It might be useful for other reasons too. I'm not saying it's a good idea for HP, just that it would be technically possible. Were some other people already talking about this in this thread? Is this already implemented? John