Changes between Version 18 and Version 19 of Commentary/GSoCMultipleInstances


Ignore:
Timestamp:
May 29, 2012 12:55:39 AM (3 years ago)
Author:
phischu
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/GSoCMultipleInstances

    v18 v19  
    1010== Dependency resolution ==
    1111
    12 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 and environment it needs to be consistent.
     12The 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.
    1313
    1414"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
     
    1818There should be at least two modes for dependency resolution.
    1919
    20 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 make it more efficient.
     20The 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.
    2121
    2222The 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.
    2323
    24 Also 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.
     24One 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.
    2525
    2626== Using Cabal without cabal-install ==
    2727
    28 Currently if Cabal is asked to configure a package from a Setup.hs script without using cabal-install some adhoc dependency resolution that only takes into account the installed packages takes place. It is a dependency resolution because it takes the set of installed packages and creates an environment. If cabal-install figures out the environment we will want to supply this step with it.
     28Currently if Cabal is asked to configure a package from a Setup.hs script without using cabal-install some adhoc dependency resolution that only takes into account the installed packages takes place. It is a dependency resolution because it takes the set of installed packages and creates an environment. After cabal-install figures out the install plan we will want to supply this step with a specific environment to build against.
    2929
    3030== Using GHC without Cabal and cabal-install ==
    3131
    32 Currently if GHC is invoked by the user it does some adhoc form of dependency resolution. The most common case of this is using ghci. If there are multiple instances of the same package in the PackageDBStack this needs to be adjusted.
     32Currently if GHC is invoked by the user it does some adhoc form of dependency resolution. The most common case of this is using ghci. If there are multiple instances of the same package in the PackageDBStack the policy used for this needs to be adjusted.
    3333
    3434== Inplace Registration ==
     
    4242== The cabal hash ==
    4343
    44 Cabal needs to have a function to hash a build configuration. cabal-install uses the hash to check if a package needs to be built or if it is already installed. Cabal needs the hash during installation because the directory of an installed package contains the hash. It is $libdir/$pkgid/$installedpackageid. It also needs the hash during registration because a package is identified by it in the PackageDB. The hash is the new InstalledPackageId (Probably not the hash alone, but also the package name (and also still the ABI hash?)).
     44Cabal needs to have a function to hash a build configuration. cabal-install uses this hash to check if a package needs to be built or if it is already installed. Cabal needs the hash during installation because the directory of an installed package contains the hash. It is $libdir/$pkgid/$installedpackageid. It also needs the hash during registration because a package is identified by it in the PackageDB. The hash is the new InstalledPackageId (Probably not the hash alone, but also the package name (and also still the ABI hash?)).
    4545
    4646A build configuration consists of the following: