Proposal: Add-on packs

[Jason Dagit]

On Wed, May 29, 2013 at 7:38 PM, Mark Lentczner
<mark.lentczner at gmail.com> wrote:
> On Wed, May 29, 2013 at 6:44 PM, Jason Dagit <dagitj at gmail.com> wrote:
>>
>> Trying to respond to this, I run smack into the question of, "Well,
>>
>> what value does/should the HP provide?" ... I think people who want
>>
>> to get started with Haskell, and have something simple but full
>> featured to install, are the audience. Would you agree?
>>
>> My impression is that the primary value of the HP is in having the HP
>> sign off on things so that newcomers have some clue as to what
>> packages to get started with. The secondary value being the convenient
>> packaging itself.
>
>
> Not quite: The primary value of HP is that it is a stable reference set of
> versions on which development can be based. If I target my libraries to HP
> releases, and then you want to use my libraries, you can target your work to
> HP release plus my libs... And if some other person wants to deploy some
> software on a server farm, they can target HP releases, and my libs and your
> libs and.... it should all work. By target here I mean code to, test to, and
> release based on. For many deployment situations, working on known stable
> sets is far more important than using the bleeding edge of every package
> that cabal thinks it can make to work.

Thanks for the explanation.

>> It's about reducing duplication and making things convenient for the
>> masses (the secondary value of the HP as I put it above). If the HP
>> team can get, say, Gtk2hs built in a redistributable way, then (the
>> logic goes) it would be nice to reuse that effort instead of forcing
>> users to reproduce a non-trivial to configure build environment.
>
>
> I still don't understand: If the Gtk2hs team cannot do this, why do you
> think the HP team can?

Let's be clear/honest here: It is possible to build Gtk2hs and I'm
talking about making a binary release/installer available (where that
makes sense ie., Windows/OSX).

What isn't likely to work is building it with little expertise or in
an unconfigured build environment. In other words, it's more than
simply running the right cabal commands. I've been assuming the HP
team is more experienced with building packages than the average
Haskell bear.

Jason