[Haskell-cafe] Getting containers updated in Stackage

[Edward Kmett]

That doesn't work if you link against ghc the library.  If I run

ghc-pkg describe ghc

on my slightly old install, it shows

depends:
    array-0.5.1.1 base-4.9.0.0 binary-0.8.3.0 bytestring-0.10.8.1
    containers-0.5.7.1 directory-1.2.6.2 filepath-1.4.1.0
    ghc-boot-8.0.1 ghci-8.0.1 hoopl-3.10.2.1 hpc-0.6.0.3
    process-1.4.2.0 template-haskell-2.11.0.0 time-1.6.0.1
    transformers-0.5.2.0 unix-2.7.2.0

If any of these are upgraded independently of ghc then every package that
depends on both ghc will start to fail to build due to needing to link two
versions of the same dependency. Examples of packages that depend on ghc
with wide distribution that lots of folks depend on in at least one
configuration of their builds? doctest

This makes this a fairly crippling distribution hazard for something like
stackage that runs the unit tests that comes with the packages it provides.
=)

Back in the day ghc used to maintain its own forks of many of its
dependencies to avoid some of these sorts of issues. It doesn't do so any
more.

-Edward

On Sun, Apr 2, 2017 at 12:24 PM, David Feuer <david.feuer at gmail.com> wrote:

> What I'm suggesting is a bit narrower: I think stack should probably just
> ignore GHC boot packages altogether, aside from the necessary ones (I think
> just ghc-prim, ghc, base, and array, but you'd have to check the full GHC
> API to be sure). Never use them, and pretend they don't exist.
>
> On Apr 2, 2017 6:47 AM, "Adam Bergmark" <adam at bergmark.nl> wrote:
>
>> Hi David,
>>
>> As far as I know stackage doesn't have a mechanism to say "this might
>> cause version mismatches but I promise it won't", is there even a way to do
>> that with Cabal (which stackage uses)?
>>
>> Cheers,
>> Adam
>>
>>
>> On Sun, 2 Apr 2017 at 01:26 David Feuer <david.feuer at gmail.com> wrote:
>>
>>> The fact that GHC needs to have its own containers shouldn't prevent a
>>> consistent package set from using a different one. The only hypothetical
>>> problem would be if the GHC API leaked containers types, but I'm pretty
>>> sure it doesn't: they're all wrapped up in newtypes and exported
>>> abstractly, unless someone's made a mistake.
>>>
>>> On Apr 1, 2017 6:09 PM, "Sven Panne" <svenpanne at gmail.com> wrote:
>>>
>>> 2017-04-01 20:53 GMT+02:00 David Feuer <david.feuer at gmail.com>:
>>>
>>> It's come to my attention that Stackage doesn't have the latest and
>>> greatest versions of containers. Stackage nightly is on 0.5.7.1, and I just
>>> released 0.5.10.2. It'd be nice to get that fixed, but the containers
>>> maintainers do not have the time to take responsibility for Stackage
>>> curation. Could whoever's responsible please take care of it?
>>>
>>>
>>> If I see this correctly, there is nothing to take care of: Stackage
>>> nightly and LTS both ship GHC 8.0.2, and that contains containers 0.5.7.1.
>>> When a new GHC is released and that ships with a new version of containers,
>>> it will be on Stackage. Apart from that, there is nothing you can do:
>>> Stackage is there to have a consistent set of packages, so containers is
>>> not even in https://github.com/fpco/stackage/blob/master/build-constrain
>>> ts.yaml, because it ships with GHC.
>>>
>>> That's at least my understanding...
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>>
>>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170403/37c718fd/attachment.html>