| But if multiple versions of the same library can be linked into one | binary, then the binary sizes will increase and therefore the memory | usage might increase and even performance might decrease a bit if the | number of cache misses increase. Well, no one is actually suggesting that! The #1 issue is that installing package P1, which depends on Q-3.4, should not break other package P2 that also depends on Q-3.4. Today it can break P2. And re-installing P2 can break P1. How does that happen? Q-3.4 depends on R 1.4-3.8 P1 depends on R-1.4 P2 depends on R-2.8 Then P1 needs Q-3.4 compiled against R-1.4 P2 needs Q-3.4 compiled against R-2.8 So the two can only co-exist if both instances of Q-3.4 can be simultaneously installed. None of this means that both instances of Q-3.4 need be part of the same executable. (That would be necessary if you wanted P1 and P2 in the same program; but maybe you don't.) They certainly could be, but allowing it has the disadvantages you describe. Simon | -----Original Message----- | From: Daniel Trstenjak [mailto:daniel.trstenjak@gmail.com] | Sent: 11 May 2015 12:05 | To: Simon Peyton Jones | Cc: Gershom B; Mikhail Glushenkov; Duncan Coutts (duncan@well- | typed.com); Ryan Trinkle; haskell-infrastructure@community.galois.com; | cabal-devel@haskell.org; ghc-devs@haskell.org; Vishal Agrawal; Haskell | Libraries | Subject: Re: Cabal and simultaneous installations of the same package | | | Hi Simon, | | > It is tantalising to me that something so critical has been so long | delayed. | > It’d be fantastic if it was done this summer. | | I'm just wondering what kind of negative side effects it might have. | | Sure, it will - most likely - make installing of cabal packages a lot | easier, especially for all non expert Haskell users. | | But if multiple versions of the same library can be linked into one | binary, then the binary sizes will increase and therefore the memory | usage might increase and even performance might decrease a bit if the | number of cache misses increase. | | It's certainly annoying to keep up with library updates, but in a way | it also pushes everyone forward to update their code bases, so if | everything just "works" - respectively is easy buildable - then this | force might be quite reduced. | | I'm just thinking e.g. of a case where you want to use at least a | certain version of a library, because you know of major | performance/bug fixes in this version, but now a considerable part of | your code base might use an older version of this library, because the | dependencies of your project haven't been updated. | | | Greetings, | Daniel