On 31/07/2014 15:31, Edward Z. Yang wrote:
We need to rethink the shadowing behaviour. It is designed to handle the case where we have the same PackageId (name + version) in two different DBs (e.g. global and local). Shadowing takes the topmost one of these (e.g. local, or rightmost -package-db flag). We can relax this requirement so long as the InstalledPackageIds are different, but what if the InstalledPackageIds are the same? Right now that's OK, because identical InstalledPackageIds implies identical ABIs, but if we change that so that InstalledPackageId is derived from the source and not the ABI, we would not be able to assume that two identical InstalledPackageIds are compatible.
I talked to Duncan about this, and he's asserted that under a Nix-like model, equal InstalledPackageIds really would imply identical ABIs. I think this would be pretty hard to achieve reliably (and if we get it wrong, segfault); Simon, perhaps you would know more about this.
Right now this is ok, because InstalledPackageIds contain the ABI, but the proposal we were going to follow (I believe) was to have InstalledPackageIds contain a hash of the source code. Since GHC compilation is (still) not deterministic, identical source hashes does not imply identical ABIs. It would be ok if the InstalledPackageId was Hash(Source,ABI), though. (or was there some reason we had to know the InstalledPackageId before compilation?)
Duncan (and shout if I understand wrong) is also keen on abolishing the shadowing algorithm completely when we have package environments and making a package environment mandatory (defaulting to a global package environment when nothing available.) The reason for this is that in a Nix model, we mostly abolish package database stacks and have a single global package database, which all packages are chucked into. In this case, the current shadowing really has no idea how to pick between two packages which shadow each other in the same database.
Yes, and I agree with Duncan, provided identical InstalledPackageId implies identical ABI. Cheers, Simon