Opened 2 years ago

Closed 2 years ago

Last modified 23 months ago

#10714 closed bug (fixed)

After implementing new installed package ID (hash of sdist), get rid of package keys

Reported by: ezyang Owned by: ezyang
Priority: normal Milestone: 8.0.1
Component: Package system Version: 7.10.2
Keywords: backpack Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


GHC tracking bug for

Externally, GHC's flags do not have to change much; a user simply passes the installed package ID to the flag currently named -this-package-key (but perhaps we should rename this.)

Internally, if we can assume that PackageKey == InstalledPackageId, we can do away with the InstalledPackageId map and get rid of the level of indirection between the bin-pkg-db (which records installed package IDs`) and GHC's guts (which record package keys).

Blocked on Cabal not actually using ABI hashes to identify packages.

Change History (6)

comment:1 Changed 2 years ago by ezyang

Keywords: backpack added

comment:2 Changed 2 years ago by ezyang

Here is a complication: what should shadowing do in this world?

Of course, within a package database, shadowing cannot occur, because there can only ever be one entry per IPID, whereas shadowing occurred when there were two entries with differing IPIDs but identical package keys.

However, there is now a thorny problem of what should be done if the user and global package database both have an entry for the same IPID! Previously, GHC assumed that the ABIs are the same, and thus they are interchangeable; however, it is possible for this invariant to be broken.

What it seems GHC should do is check the ABI of the package in question, and if they match filter out as before. However, if the ABIs do not match, we can either (1) complain loudly, or (2) shadow all prior references to the IPID so that we can safely use the newer IPID. The second possibility seems like a lot of complication for a case that really shouldn't happen, so let's not do it.

comment:3 Changed 2 years ago by ezyang

Another point: when Backpack is back in the picture, UnitKey only equals InstalledPackageId if the package in question is a non-Backpack package (installed package ID is per package, but a package can have multiple units.)

comment:4 Changed 2 years ago by Edward Z. Yang <ezyang@…>

In 5b0191f7/ghc:

Update Cabal to HEAD, IPID renamed to Component ID.

This commit contains a Cabal submodule update which unifies installed
package IDs and package keys under a single notion, a Component ID.
We update GHC to keep follow this unification.  However, this commit
does NOT rename installed package ID to component ID and package key to
unit ID; the plan is to do that in a companion commit.

    - Compiler info now has "Requires unified installed package IDs"

    - 'exposed' is now expected to contain unit keys, not IPIDs.

    - Shadowing is no more.  We now just have a very simple strategy
      to deal with duplicate unit keys in combined package databases:
      if their ABIs are the same, use the latest one; otherwise error.
      Package databases maintain the invariant that there can only
      be one entry of a unit ID.

Signed-off-by: Edward Z. Yang <>

Test Plan: validate

Reviewers: simonpj, austin, bgamari, hvr, goldfire

Subscribers: thomie

Differential Revision:

GHC Trac Issues: #10714

comment:5 Changed 2 years ago by ezyang

Resolution: fixed
Status: newclosed

comment:6 Changed 23 months ago by thomie

Milestone: 8.0.1
Note: See TracTickets for help on using tickets.