Hello Duncan, Sunday, April 27, 2008, 11:42:01 PM, you wrote:

...

...

The problem is that if you install pretty, Cabal will suddenly cease working until you recompile it. It depends on a version of pretty which gets bundled with GHC is purportedly of the same version as the one on hackage, but the two aren't binary compatible. So when it tries to use it, everything goes boom.

The solution is not to identify installed packages by their name and version but by a hash that identifies the package ABI.

probably not ABI (it should be the same), but random number generated when compilation (build) occurs -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On Sun, Apr 27, 2008 at 9:25 PM, Duncan Coutts wrote:

On Sun, 2008-04-27 at 23:49 +0400, Bulat Ziganshin wrote:

...

Hello Duncan,

Sunday, April 27, 2008, 11:42:01 PM, you wrote:

...

...

...

The problem is that if you install pretty, Cabal will suddenly cease working until you recompile it. It depends on a version of pretty which gets bundled with GHC is purportedly of the same version as the one on hackage, but the two aren't binary compatible. So when it tries to use it, everything goes boom.

...

The solution is not to identify installed packages by their name and version but by a hash that identifies the package ABI.

probably not ABI (it should be the same), but random number generated when compilation (build) occurs

The package name and version do not identify an ABI. You change the ABI by using -O0 vs -O1.

Also, I think modeling build processes as randomness isn't the right approach. Build are really pure functions but with a rather large number of inputs. The Nix approach is to identify them all and calculate a hash of them all and use that to identify each built package.

The main thing I'd like to borrow from the Nix approach is the ability to back out of the package change. I'm really more bothered about the fact that it left me with a nonfunctioning build system (until someone pointed out runghc would compile everything from source) than anything else. :-)

On Sun, Apr 27, 2008 at 9:52 PM, Duncan Coutts wrote:

On Sun, 2008-04-27 at 21:29 +0100, David MacIver wrote:

...

The main thing I'd like to borrow from the Nix approach is the ability to back out of the package change. I'm really more bothered about the fact that it left me with a nonfunctioning build system (until someone pointed out runghc would compile everything from source) than anything else. :-)

Yes, that's one of its great features, that installed packages are never modified, that you just add new ones and GC old ones.

Though in this case you didn't modify any package you just masked it. At least I assume that's what you did. In which case the solution was to unregister the version that was masking the normal one.

No, the problem seems to be that because the old and new copies of pretty have the same version number the installation of it overwrote the old one with an incompatible file.

On Sun, Apr 27, 2008 at 10:34 PM, Duncan Coutts wrote:

On Sun, 2008-04-27 at 22:07 +0100, David MacIver wrote:

...

On Sun, Apr 27, 2008 at 9:52 PM, Duncan Coutts wrote:

...

On Sun, 2008-04-27 at 21:29 +0100, David MacIver wrote:

...

The main thing I'd like to borrow from the Nix approach is the ability to back out of the package change. I'm really more bothered about the fact that it left me with a nonfunctioning build system (until someone pointed out runghc would compile everything from source) than anything else. :-)

Yes, that's one of its great features, that installed packages are never modified, that you just add new ones and GC old ones.

Though in this case you didn't modify any package you just masked it. At least I assume that's what you did. In which case the solution was to unregister the version that was masking the normal one.

No, the problem seems to be that because the old and new copies of pretty have the same version number the installation of it overwrote the old one with an incompatible file.

So it depends if you installed 'pretty' as a global or user package. If as global then you'd have replaced the registration for the pre-existing instance. If as user then it's just the masking that I was mentioning previously.

I installed it as a global package. In future I think I'm very likely to install a lot more as user packages to avoid this sort of issue.