Cabal and GHC
Dan Burton
danburton.email at gmail.com
Thu Nov 22 18:21:51 CET 2012
>
> "Cabal should do the same plan no matter what the state of the database
> is" which is in tension with "don't install more than you have to."
This I like, except instead of "cabal", it should be something new.
With a combination of curators and a synchronized release schedule,
I see a system like this running very smoothly,
and you could even bridge the gap between both ideals.
A social solution will be much more effective than a technical solution.
I still agree with Michael's post that it would be best to let cabal keep
doing
its thing, and instead create a new, more convenient tool on top of it
with this added social layer of curation and synchronization.
Perhaps the best solution would be to add the functionality Simon suggests,
as well as adopting the hopelessly complex Nix-style package management
(referring to Brandon's comments),
and then giving sense to it with a social layer on top.
-- Dan Burton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20121122/c80b27c9/attachment.htm>
More information about the Libraries
mailing list