ghc-boot is reinstallable

[mpickering]

#8489 #8501 added ghc-boot to the nonUpgradeablePackages list but I don't see why ghc-boot is not reinstallable. It is a normal dependency of ghc like containers (which is reinstallable).

It would be good to document what a nonUpgradeablePackage is to avoid additional packages being added here in future.

[andreabedini]

I think the PR is #8501 and the commit that made the change is 09c90de that made the change. Reading through #8501 and #8489 I have the impression nobody here is sure about what should be non-reinstallable (or non-upgradeable? or whatever this means)

Can GHC provide guidance and a source of truth for the list of relevant packages?

[ulysses4ever]

I have the same impression as Andrea.

@grayjay may be interested to opine on this issue.

[grayjay]

I agree that no one knew how to determine the list of non-upgradable packages. It looks like ghc was the only non-ugradable package that was causing a problem in #8489.

This comment has some notes that might be useful for finding the correct list of packages: #8712 (comment)

[gbaz]

Yes, please somebody who knows what they are doing take ownership of this and help! :-)

[bgamari]

My understanding is that the set of non-reinstallable packages should only includes those which cannot be rebuilt using a GHC installation and Hackage-published source distribution. There are a few reasons why this might be true:

• the package overrides its unit ID with -this-unit-id, which would result in multiple indistinguishable packages (having potentially different ABIs) with the same unit ID after reinstallation
• definition of wired-in declarations which tie the package to a particular compiler (e.g. we can't build link against base-4.18.0.0 using GHC 9.6.1
• packages that rely on configuration provided by GHC's build system; in the future such configuration should be fixed to rather be defined by a configure script or custom Setup.

This list should currently include:

• ghc, since we are still working on making ghc#19896 feasible (see ghc#20742)
• ghc-prim (due to use of -this-unit-id and wired-in declarations)
• base (due to use of -this-unit-id and wired-in declarations)
• rts (due to strong ABI dependence)
• template-haskell (due to use of -this-unit-id)
• ghc-bignum (due to use of -this-unit-id)

[ulysses4ever]

@bgamari thanks a lot, that's very clear. Do you have an idea about non-reinstallable vs. non-upgradable? Is there a slightest difference between the two notions do you think? Our guess is that there may be none, see this thread.

[bgamari]

@bgamari thanks a lot, that's very clear. Do you have an idea about non-reinstallable vs. non-upgradable? Is there a slightest difference between the two notions do you think? Our guess is that there may be none, see this thread.

My sense is that currently there should be no difference between non-upgradeable and non-reinstallable packages. Moreover, at the moment I don't see why we would need such a distinction in the future.

However, in the future (when ghc is a reinstallable package) we may need some notion of constraints on compile-time dependencies arising from the compiler being used. Specifically, consider a package p which uses a compiler plugin in its build process. cabal-install must someone ensure that the ghc library linked against by the plugin is the same as that linked by the ghc-bin executable used for the build.

[bgamari]

I have opened #9092 addressing this.