| 52 | | Currently only a small part of the configuration of an installed package is stored and only this small part can be used to determine if it is valid to depend upon a certain installed package. For example it is not tracked if a package was built with profiling support. We could enrich the InstalledPackageInfo with a lot of information about the package configuration. Or we could hash the package configuration and only add this hash to the InstalledPackageInfo. |
| | 53 | "so I see two general options for communicating knowledge about build flavors to the solver: |
| | 54 | |
| | 55 | (1) "the direct way": |
| | 56 | i.e., all info is available to ghc-pkg and can be communicated back to Cabal and therefore the solver |
| | 57 | the solver can therefore figure out if a particular package is suitable to use or not, in advance |
| | 58 | |
| | 59 | (2) "the agnostic way" |
| | 60 | this is based on the idea that the solver at first doesn't consider installed packages at all. it'll just do resolution on the source packages available. |
| | 61 | taking all build parameters into account, Cabal hashes will be computed. |
| | 62 | these can then be compared to hashes of installed packages. |
| | 63 | reusing installed packages instead of rebuilding them is then an optimization of the install plan. |
| | 64 | this doesn't require that ghc-pkg is actually directly aware of all the build parameters, as long as the hash computation is robust." -- kosmikus |
| | 65 | |
| | 66 | The options are to support either both by putting all info into InstalledPackageInfo or to support only (2) by just putting a hash into InstalledPackageInfo. The disadvantage of supporting both is that InstalledPackageInfo would have to change more often. This could be fixed by making InstalledPackageInfo extensible. The advantages are that the additional info might be useful for other tools and that more complex rules for compatibility are possible for example non-profiling libs can depend on profiling libs. It would also be better for showing the user how two instances differ. The disadvantage of going for only (2) is that it is a big change and might cause problems with other Haskell implementations. Also if a package only exists installed and not in source form it is completely ignored. |
| 67 | | |
| 68 | | == Dependency resolution == |
| 69 | | |
| 70 | | The dependency resolver currently comes up with an install plan. An install plan is similar to an environment. Like an environment it is a set of installed packages. But it may also contain configurations for packages that are not installed yet. Like an environment it needs to be consistent. |
| 71 | | |
| 72 | | "An installation plan is a set of packages that are going to be used together. It will consist of a mixture of installed packages and source packages along with their exact version dependencies." -- InstallPlan documentation |
| 73 | | |
| 74 | | The dependencies of a package version are what is currently listed under dependencies in a cabal file. A list of packages with version contraints that may be used to build this package version. |
| 75 | | |
| 76 | | There should be at least two modes for dependency resolution. |
| 77 | | |
| 78 | | The dependency resolver uses the dependencies of all possible source packages to find a set of package configurations. This is already an install plan. It then in this set replaces configurations for already installed packages by the installed package to avoid rebuilding those packages. |
| 79 | | |
| 80 | | The other mode is what is currently done. The set of installed packages is taken into account. This might avoid more rebuilding but people might not always get the latest packages. |
| 81 | | |
| 82 | | One drawback of ignoring installed packages is that there might be installed packages for which the source is not available. If the source is not available and installed packages are ignored those packages can not appear in the install plan. |
