Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Haskell-cafe] Is it just me... or is cabal/hackage a little broken?

1 view
Skip to first unread message

Bardur Arantsson

unread,
Dec 22, 2009, 6:14:54 PM12/22/09
to haskel...@haskell.org
Hi all,

Sorry about the inflammatory title, but I just got this message from an
uploaded package ("hums"):

Warning: This package indirectly depends on multiple versions of the
same package. This is highly likely to cause a compile failure.

The thing is, I got the same message while trying to compile locally and
it turned out that all I had to do was to

$ cabal install <PKG-X>

on all the packages that cabal complained about. So why doesn't hackage
do this automagically when I upload a package? How am I supposed to know
which versions of my package's dependencies (or their dependencies) are
the most recently compiled by hackage?

For the record: I did do a "Check package" upload first. It didn't complain.

Is this an intractable problem? Am I being overly demanding (probably)?

Cheers,

B�r�ur


_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Brandon S. Allbery KF8NH

unread,
Dec 22, 2009, 8:43:14 PM12/22/09
to Bardur Arantsson, haskel...@haskell.org
On Dec 22, 2009, at 18:14 , Bardur Arantsson wrote:
> Warning: This package indirectly depends on multiple versions of the
> same package. This is highly likely to cause a compile failure.
>
> The thing is, I got the same message while trying to compile locally
> and it turned out that all I had to do was to
>
> $ cabal install <PKG-X>
>
> on all the packages that cabal complained about. So why doesn't
> hackage do this automagically when I upload a package? How am I
> supposed to know which versions of my package's dependencies (or
> their dependencies) are the most recently compiled by hackage?


You got lucky; your case can be solved that way. In the general case,
you can have packages that work only with certain versions of other
packages, and you can potentially end up with nasty unsolvable
dependency loops as a result. (Look for "diamond dependency problem"
on Google if you want the ugly details.)

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] all...@kf8nh.com
system administrator [openafs,heimdal,too many hats] all...@ece.cmu.edu
electrical and computer engineering, carnegie mellon university KF8NH


PGP.sig

Duncan Coutts

unread,
Dec 23, 2009, 5:44:22 PM12/23/09
to Bardur Arantsson, haskel...@haskell.org
On Wed, 2009-12-23 at 00:14 +0100, Bardur Arantsson wrote:
> Hi all,
>
> Sorry about the inflammatory title, but I just got this message from an
> uploaded package ("hums"):
>
> Warning: This package indirectly depends on multiple versions of the
> same package. This is highly likely to cause a compile failure.
>
> The thing is, I got the same message while trying to compile locally and
> it turned out that all I had to do was to
>
> $ cabal install <PKG-X>
>
> on all the packages that cabal complained about.

Right. I wrote a simple constraint solver for cabal-install to solve
this problem (the diamond dependency problem).

> So why doesn't hackage do this automagically when I upload a package?

The single hackage buildbot does not do anything smart. It does not use
the cabal-install solver, so it regularly runs into the diamond dep
problem.

> How am I supposed to know which versions of my package's dependencies
> (or their dependencies) are the most recently compiled by hackage?

You're not. My suggestion is don't worry about it not building on
hackage. The quality of the build results there just are not that good.

For the new hackage server we're using a different design that will
generate good build results.

> For the record: I did do a "Check package" upload first. It didn't complain.

Right. It's not a problem with the package itself.

> Is this an intractable problem? Am I being overly demanding (probably)?

No, not intractable. The cabal-install solver can handle it most of the
time.

Duncan

0 new messages