I can no longer maintain containers

[David Feuer]

Does Cabal balk if you try to expose a module provided by a dependency?
That seems quite strange. If so, could we rename the modules in the
splinter packages and then provide modules in the meta-package that just
export them wholesale?

module Data.Sequence2 where ... -- in a sequence package
module Data.Sequence (module Data.Sequence2) where import Data.Sequence2 --
in containers

It's not so pretty, but it seems sane.
On Apr 3, 2016 10:28 PM, "Phil Ruffwind" <rf at rufflewind.com> wrote:

> Correct me if I'm wrong: my understanding of how Cabal currently works is
> that if containers becomes a meta-package for other packages (say,
> containers-map and containers-seq), then users of the package would have to
> explicitly specify containers-map and containers-seq in the .cabal file.
> Additionally, to provide compatibility with older versions, there would
> need to be some sort of conditional logic too.  This wouldn't be easy to
> automate, since one also needs to convert the version bound for containers
> into corresponding version bounds for the subpackages.
>
> Hence, I think unless there is a way to make it 100% compatible with
> downstream splitting the package is probably not a good idea, given that containers
> is such a fundamental package in the ecosystem.  Looking at
> http://packdeps.haskellers.com/reverse , there are about 3000 packages
> downstream that depend on it (one of highest among the list).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160403/5d055481/attachment.html>