Changes between Version 21 and Version 22 of Commentary/GSoCMultipleInstances


Ignore:
Timestamp:
Jun 17, 2012 11:20:54 AM (3 years ago)
Author:
phischu
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/GSoCMultipleInstances

    v21 v22  
    2525A unique number could be the number of packages installed for example /usr/local/lib/GLUT-2.3.0.0-87 or the number of instances of this version installed for example /usr/local/lib/GLUT-2.3.0.0-2 or a random number for example /usr/local/lib/GLUT-2.3.0.0-83948393212. The advantages I see are that not much information is needed to come up with the file path and this seems to be robust against other design decisions we make now or in the future.
    2626
    27 == Simple dependency resolution in Cabal and GHC ==
     27== Dependency resolution in Cabal and GHC ==
    2828
    29 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 the policy used to select a single one needs to be adjusted. The user should be warned that this happened. Ideas:
     29Currently 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 to select a single one prefers DBs higher in the stack. It then prefers packages with a higher version. We need a third criterium if there are multiple packages with the same version in the same PackageDB. Ideas:
    3030
    3131 * build a complex solver into GHC
     
    3535 * latest
    3636
    37 Picking the most recently installed instance seems like the best idea right now. There are at least two ways to track which of the installed instances was most recently installed. In either you add a timestamp or the count of instances to InstalledPackageInfo. Tracking the count means that you would lose the possibility to migrate packages between machines.
     37Picking the most recently installed instance seems like the best idea right now. There are at least two ways to track which of the installed instances was most recently installed. In either you add a timestamp or the count of instances to InstalledPackageInfo. Tracking the count means that you would lose the possibility to migrate packages between machines. So we want to track timestamps.
     38The user should be informed about ambiguities and how they are resolved.
    3839
    3940Currently if Cabal is asked to configure a package from a Setup.hs script without using cabal-install some adhoc dependency resolution takes place too.
     
    4142== Garbage Collection ==
    4243
    43 It should be possible to have a garbage collection remove unneeded packages. It has to be interactive because there might be dependencies not known to Cabal and ghc-pkg. Sandboxes come in handy because they can be removed without affecting anything else.
     44It should be possible to have a garbage collection remove unneeded packages. It has to be interactive because there might be dependencies not known to Cabal and ghc-pkg. Sandboxes are useful for the user to keep track of what should be removable without causing too much damage.
    4445
    4546== Identifying packages ==
     
    4849The InstalledPackageId as currently defined is unsuitable to uniquely identify installed package instances.
    4950
    50 == Avoiding rebuilding a package ==
     51== Dependency resolution in cabal-install ==
    5152
    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":
     56i.e., all info is available to ghc-pkg and can be communicated back to Cabal and therefore the solver
     57the solver can therefore figure out if a particular package is suitable to use or not, in advance
     58
     59(2) "the agnostic way"
     60this 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.
     61taking all build parameters into account, Cabal hashes will be computed.
     62these can then be compared to hashes of installed packages.
     63reusing installed packages instead of rebuilding them is then an optimization of the install plan.
     64this 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
     66The 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.
    5367
    5468== The Cabal hash ==
     
    6579
    6680OS dependencies are not taken into account because i think it would be very hard.
    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.
    8381
    8482== Released and Unreleased packages ==