ghc-pkg does handle unitids
I base the summary and the description on a single observation, see below. Sorry should this turn out to be a deduction too aggressive.
Assumed problem description
New-style package-dbs can contain the same (package, version) entry multiple times, as entries are identified using an additional hash. I'll call the full identifier "unitId". The ghc-pkg interface seems to not support specifying full unitIds, i.e. "my-package-0.1.0.0-somehash" seems to be interpreted like "my-package-0.1.0.0-*". This is both a missing functionality and a bug:
- many operations make sense per-unitId, not just per (package, version)
- The fact that my-package-0.1.0.0-otherhash is unregistered by "ghc-pkg unregister my-package-0.1.0.0-somehash" is quite surprising.
Observation
- Take a package-db containing the same (package, version) entry with two different hashes, e.g.
- semigroupoids-5.2.1-2f552e489ce3109c2672606e2dc6e33c4f38174da930d5db0bb0dafbb4dccae8
- semigroupoids-5.2.1-e50d44ead36c6b8428c9417007cee15bd9cbe3a2906c19553366d94b15c2471e
I suggest making a copy of some existing (cabal store) db.
- call
ghc-pkg --package-db my-copy unregister semigroupoids-5.2.1-2f552e489ce3109c2672606e2dc6e33c4f38174da930d5db0bb0dafbb4dccae8 - test
ghc-pkg --package-db my-copy list semigroupoids-5.2.1
Expected result: semigroupoids-5.2.1-e50d44ea.. is still registered
Observed result: empty list
Impact
This blocks the use-case of a garbage-collection for the global new-style package db "store".
Trac metadata
| Trac field | Value |
|---|---|
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | ghc-pkg |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |