QRE: Cabal and simultaneous installations of the same package

[Simon Peyton Jones]

|  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 at gmail.com]
|  Sent: 11 May 2015 12:05
|  To: Simon Peyton Jones
|  Cc: Gershom B; Mikhail Glushenkov; Duncan Coutts (duncan at well-
|  typed.com); Ryan Trinkle; haskell-infrastructure at community.galois.com;
|  cabal-devel at haskell.org; ghc-devs at 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