|Version 9 (modified by phischu, 12 months ago)|
It is a problem that cabal does not support multiple instances of the same package version installed at the same time. Instead of installing them next to each other it overwrites the previous instance. This causes packages that depended upon the overwritten instance to break. The solution is to never overwrite an installed package. In the case of inplace registrations the overwriting has already taken place which is a problem.
Released and Unreleased packages
If we cabal install a package that is released on hackage we call this a clean install. Those should not be used to satisfy dependencies but rather to bring a package into scope in ghci to play with it. If we cabal install an unreleased package we call this a dirty install.
The cabal hash
The idea is to identify installed packages by a hash of the information needed to build them. This hash is the new InstalledPackageId?. The new installation directory for each instance is $libdir/$pkgid/$installedpackageid. The hash is computed during installation in installLib as well as during registration in generateRegistrationInfo.
The hash contains the following information:
The hashes of all the packages that are actually used for compilation. Those are available in the installedPkgs field of LocalBuildInfo?.
The compiler, its version and its arguments and the tools and their version and their arguments. Available from LocalBuildInfo? also.
The source code. This is necessary because if the source code changes the result of compilation changes. For released packages i would assume that the version number uniquely identifies the source code but what about unreleased packages?
The ABI hash becomes a field of InstalledPackageInfo?. (What is it needed for?)
For inplace package registration any packages with the same location must be unregistered.
Who has assumptions about the directory layout of installed packages?
Garbage Collection of unused packages?
Custom Builds and BuildHooks??