The Grinch stole all the vowels: Odd naming in .cabal/store (macOS)

[andreasabel]

This affects only macOS, I think.
If I look into .cabal/store, I see:

~/.cabal/store/ghc-8.10.3$ ls
Dff-0.4.0-e2417685                 n-0.4.1-98d17fa3
Dff-0.4.0-e6c8ed46                 nclsd-xcptns-1.0.3-7f7ef320
HTF-0.14.0.3-710f7bdf              ndxd-trvrsbl-0.1-9a7dbfcd
HUnt-1.6.1.0-74fb3e3f              ndxd-trvrsbl-0.1-ec48aff0
HsYAML-0.2.1.0-7c9cf1ca            ndxd-trvrsbl-nstncs-0.1-be410491
QckChck-2.14.2-3e204cf1            nrdrd-cntnrs-0.2.13.0-0b73c8ca
QckChck-2.14.2-605cea58            nrdrd-cntnrs-0.2.13.0-a7a57927
ShllChck-0.7.1-f3d01607            ns-trmnl-0.11-fcd1ff58
...

Seriously! The Grinch stole all the vowels.
I cannot help feeling trolled by cabal v2. (Which I am still trying to learn.)
#5399 (comment)
Apparently, removing the vowels should help the Mach-O linker with its space limitations.
https://github.com/typedrat/cabal/blob/638c78e790721566780dbf75a2e6f884ceafa970/cabal-install/Distribution/Client/PackageHash.hs#L137-L145
I feels I am on the C64 again. Sure this isn't an Easter egg?

Questions:

• Just how many bytes are saved by dropping the vowels?
• Does this measure guarantee that things will work? (How? And how does this fight super long package names?)
• Do thinks break without the measure?
• Is this a systematic fix of the problem?
• How does this weigh against the confusion of the users?

Odd.

[phadej]

Just how many bytes are saved by dropping the vowels?

unordered-containers
nrdrd-cntnrs

About a third?

Does this measure guarantee that things will work? (How? And how does this fight super long package names?)

No it doesn't, but things are less likely to hit the limit

Do things break without the measure?

Yes. See e.g. #5220

Is this a systematic fix of the problem?

No. People work on it though, e.g. #7094

How does this weigh against the confusion of the users?

It's a necessary hack, for now.

[andreasabel]

@gbaz: I protest, this isn't a just a "user-question". I strongly hope this crutch will be dropped as soon as possible! It is already requiring workarounds, see agda/agda@b44a0bd.

[gbaz]

Sorry, I tried to read through the big diff, but I can't figure out what the workaround is there? It seems to me that the naming in cabal's store should be an internal detail that users don't have to concern themselves with.

It seems like Big Sur has improved linker limitations that existed with prior mac os versions, but this is entirely an ad-hoc thing we noticed at work, not something I have any clear documentation of, and even if this is true, we can't remove the vowel stripping anytime soon. If we can confirm that it is true, and to what degree it is true (i.e. did they just bump the limit, remove it, raise it drastically?), then maybe we could start a clock at least.

[andreasabel]

@gbaz wrote:

Sorry, I tried to read through the big diff, but I can't figure out what the workaround is there? It seems to me that the naming in cabal's store should be an internal detail that users don't have to concern themselves with.

Sorry for the long diff (commits got squashed), the workaround is here:
https://github.com/agda/agda/blob/731f300deac14e10792a0bbf22c86cbe0c9c7e4b/test/Utils.hs#L315-L327

To normalize an error message, we replace Agda-$VER-$HASH by <<Agda-package>>. However, due to the OP, we also have to consider Agd-$VER-$HASH, on macOS.

I agree that "the naming in cabal's store should be an internal detail that users don't have to concern themselves with", but unfortunately, is leaks e.g. through error locations given by HasCallStack and the like.

Also, as long as there is no automatic garbage collection, the user might have to go into .cabal/store and manually delete stuff, and is then confronted with cryptic packages like sn-1.4.7.1-51bc2765 (quiz: where did this one come from?).

[phadej]

sn-1.4.7.1-51bc2765

easy, aeson.

More seriously: if you just go and selectively delete stuff in .cabal/store you most likely break everything, simpler to delete whole store. OTOH, you can look into into cabal-hash.txt files: they look something like:

% cat /cabal/store/ghc-8.2.2/aeson-1.5.6.0-65f6f8abc52f93055181a621a9052f070efa24aa2c62e9c1b6ce8b90fc2fdae2/cabal-hash.txt 
pkgid: aeson-1.5.6.0
component: ComponentLib
src: 0361c34be3d2ec945201f02501693436fbda10dcc549469481a084b2de22bfe8
pkg-config-deps: 
deps: attoparsec-0.14.1-c24c67c02ee9218c31692d203c6c1d2a724ed3f7bdbc79c2141cf9de984bd0cd, base-4.10.1.0, base-compat-batteries-0.11.2-b9b16c908a3f04cf0802928ac16bf54a58b443ed3d9896b3248886da06cf52e5, bytestring-0.10.8.2, containers-0.5.10.2, contravariant-1.5.5-4adff088b7d750ecf7d3c52be2c3606cce80234b3b0d4b496244e3ee93a4f0f3, data-fix-0.3.2-82d9427a473a25f9b3ba3a61e48b5a191244e717e8890e12123e7ba96074b481, deepseq-1.4.3.0, dlist-1.0-be8ac3510ea30b30d04e38f4cbe8f404b697da8c3938c54151872ae8c3885115, ghc-prim-0.5.1.1, hashable-1.3.2.0-58027f2f2c3477eaaa874990d188b97b0debea1c4b5842fd399d403832cf2640, primitive-0.7.1.0-fcdfd35f70cea734e35ea53fa899add072a15fd0691c37c1898fc3a228eb1d1e, scientific-0.3.7.0-88de3ed3c1727f6edb60eb145705948194c3f3b4bd9a613b06bdabd989822b2e, strict-0.4.0.1-b6dce21bb07454c8b93e8969e10bf03112cca8bfd69c9f37fef8f4f94b3fd21e, tagged-0.8.6.1-a90c974de1d25b206713c0c5a3be6bd406292c5ac34b47e358fcb4adea808db8, template-haskell-2.12.0.0, text-1.2.4.1-3dcb090626d10a059b7e10441942d9e839bb776c3d74fbe3fef3582b4dcc9066, th-abstraction-0.4.2.0-c0ab0bd4daa390f4f1b3d31b0e37eea24b0834a0152c60554423d6c3ce0b5e7a, these-1.1.1.1-ff33d9736624d26942b8085943de4f7461c61e38525d9cb2b397703561a5ae54, time-1.8.0.2, time-compat-1.9.6-19e52692d4cfdf66be49f66f0dcdd62c37036f14f7dfec5f3c0a438626ab1618, unordered-containers-0.2.14.0-136afc4d4166d90a7333c7b40eac8a4dfe88fc171a4fb0f50896c5021416872d, uuid-types-1.0.5-f8e2ba0e3824070865d5f3dd87d1ad7fa211a829cc3528c026cbb00315df7836, vector-0.12.3.0-7291eb8fe75d2c5daedc5af82393c61876665d118660d03d72b2e19739ee4fe8
compilerid: ghc-8.2.2
platform: x86_64-linux
flags: -bytestring-builder -cffi -developer -fast
shared-lib: True
stripped-exe: False
debug-info: 0

It's great that there are these "receipt" files!

[andreasabel]

sn-1.4.7.1-51bc2765

easy, aeson.

Congrats, @phadej! (I suppose aeson was too easy, it's ubiquitous.)

[jneira]

@andreasabel is there some actionable here? do you think we should keep this open, tracking and blocked on a upstream os clear and coumented fix?

[andreasabel]

Are we tracking the upstream issue somewhere? Maybe it would be good to a add a pointer here.
I think we should keep this open so that we can remember to revert the workaround as soon as upstream is fixed. (Unfortunately, we won't get any help from github with the tracking unless the upstream issue is also on github (very unlikely).)

[angerman]

This won't be fixes in macOS ever; they've set the hard limit and the only known program to me that has an issue with this is GHC, and it's almost exclusively due to GHCs own making. More recent GHCs are better at not polluting the load command space as much though, by dead-stripping unused dependencies, or those that can be recursively loaded. See https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3947

[gbaz]

I'm not so sure of that. I think they may have even already bumped the linker cmd limit on the very latest "OS X" -- based on the fact that nix derivations which got to large were failing to build before, and this was solved (at our company) by upgrading to Big Sur. They don't really document this stuff though, so its all slightly guesswork. Even if this is the case, we would need to A) verify, and B) leave the hack in for at least a few more releases until dropping support for anything before Big Sur was already compelled by other considerations.

[tfausak]

I think I ran into this problem. I had a build fail with a typical unused dependency warning: https://github.com/tfausak/monadoc/runs/5713573255?check_suite_focus=true#step:13:17

<no location info>: error: [-Wunused-packages, -Werror=unused-packages]
    The following packages were specified via -package or -package-id flags,
    but were not needed for compilation:
      - cs-nsnstv-1.2.1.0-dd1e15eb

Except of course cs-nsnstv doesn't exist on Hackage or locally. It's not in my package description either. It seems like Cabal (or perhaps GHC?) was trying to tell me I had an unused dependency on case-insensitive, but the warning message stripped the vowels out of the package name.

I eventually figured it out, but this was very puzzling. https://twitter.com/taylorfausak/status/1508265860917600257

[typesanitizer]

I'm not so sure of that. I think they may have even already bumped the linker cmd limit on the very latest "OS X" -- based on the fact that nix derivations which got to large were failing to build before, and this was solved (at our company) by upgrading to Big Sur.

If you look at the dyld code, it looks like this size limitation was present with dyld2, defined as:

#define MAX_MACH_O_HEADER_AND_LOAD_COMMANDS_SIZE (32*1024)

(I made that search based on the error message in this Nix issue.)

However, if you look at the latest official release of dyld, that macro is not present, and that constant doesn't seem to show up either. (search query)

According to the docs, there used to be some fallback to dyld2 mode previously:

Background: dyld3 policy

Recent OS releases, contained both dyld2 and dyld3, and we had a policy on when to use dyld3:

• macOS: programs built into the OS used dyld3, unless a "root" was detected
• macOS: All Almond (iPad apps) run in dyld3 mode
• macOS: All other programs (including all 3rd party apps) run in dyld2 mode

but that fallback is no longer present.

dyld4 constraints

With dyld4 there is no choice of falling back to dyld2. There is only dyld4.

[jneira]

at very least this hack:

It seems to me that the naming in cabal's store should be an internal detail that users don't have to concern themselves with.

so it should not leaked to the user while we don't remove it. Reading the hash file or whatever. Hack on top of the hack, but hacks work that way, that is the main reason we have to avoid them hard
could not we decouple the store name scheme from the package identifiers passed to ghc?

[andreasabel]

could not we decouple the store name scheme from the package identifiers passed to ghc?

This would be optional.
Wouldn't you need a new feature in GHC for this? Meaning that GHC gets both a unique package identifier and a string how to print it to the user?

Just remind of the scope of this issue: the unique package identifiers (with hashes) also end up in the .ghc.environment files (e.g. I see package-id nbndd-dlys-0.1.1.1-a6c4da69 in my environment file for hackage-server). So, if you would want to pass a readable name to GHC along with it, you would also have to change the format of entries in the environment files.

Let's keep this hack and rather organize package identifier deobfuscation schools (PIDS) and yearly tournaments where Haskell programmers compete over reconstructing the real names:
Which package is behind nbndd-dlys? You have 10 seconds to guess! The clock is ticking...

(Apologies for the sarcasm. This is just too easy a target. Can't resist.)

[jneira]

This would be optional.
Just remind of the scope of this issue: the unique package identifiers (with hashes) also end up in the .ghc.environment

I would say ghc displaying user face errors with the shortened names is worse than leak them to the env file, as it is a implementation detail from the cabal-install perspective imo.
The title does not talk about env files but the store so other users has added their issues here, maybe we should open a new issue, more generic?

Wouldn't you need a new feature in GHC for this? Meaning that GHC gets both a unique package identifier and a string how to print it to the user?

Not sure, windows package names in the store are being also shortened to workaround its max path limit (base16-bytest_ for base16-bytestring) and afair those names are not leaked to ghc (but i should have to doublecheck it)
Nevertheless, we have the package db between ghc and the file system and we could use it as indirection layer, no?

[jneira]

Not sure, windows package names in the store are being also shortened to workaround its max path limit (base16-bytest_ for base16-bytestring) and afair those names are not leaked to ghc (but i should have to doublecheck it)

checked:

<no location info>: error: [-Wunused-packages, -Werror=unused-packages]
    The following packages were specified via -package or -package-id flags,
    but were not needed for compilation:
      - base16-bytestring-1.0.2.0

and in the cabal ghc call we can see the package id with the name shortened and the hash:

Running: "D:\ghcup\bin\ghc-8.10.7.exe" "--make" "-no-link" "-fbuilding-cabal-package" "-O" "-static" "-outputdir" "D:\ws\haskell\issues\testpkgids\dist-newstyle\build\x86_64-windows\ghc-8.10.7\testpkgids-0.1.0.0\x\testpkgids\build\testpkgids\testpkgids-tmp" "-odir" "D:\ws\haskell\issues\testpkgids\dist-newstyle\build\x86_64-windows\ghc-8.10.7\testpkgids-0.1.0.0\x\testpkgids\build\testpkgids\testpkgids-tmp" "-hidir" "D:\ws\haskell\issues\testpkgids\dist-newstyle\build\x86_64-windows\ghc-8.10.7\testpkgids-0.1.0.0\x\testpkgids\build\testpkgids\testpkgids-tmp" "-stubdir" "D:\ws\haskell\issues\testpkgids\dist-newstyle\build\x86_64-windows\ghc-8.10.7\testpkgids-0.1.0.0\x\testpkgids\build\testpkgids\testpkgids-tmp" "-i" "-iD:\ws\haskell\issues\testpkgids\dist-newstyle\build\x86_64-windows\ghc-8.10.7\testpkgids-0.1.0.0\x\testpkgids\build\testpkgids\testpkgids-tmp" "-iapp" "-iD:\ws\haskell\issues\testpkgids\dist-newstyle\build\x86_64-windows\ghc-8.10.7\testpkgids-0.1.0.0\x\testpkgids\build\testpkgids\autogen" "-iD:\ws\haskell\issues\testpkgids\dist-newstyle\build\x86_64-windows\ghc-8.10.7\testpkgids-0.1.0.0\x\testpkgids\build\global-autogen" "-ID:\ws\haskell\issues\testpkgids\dist-newstyle\build\x86_64-windows\ghc-8.10.7\testpkgids-0.1.0.0\x\testpkgids\build\testpkgids\autogen" "-ID:\ws\haskell\issues\testpkgids\dist-newstyle\build\x86_64-windows\ghc-8.10.7\testpkgids-0.1.0.0\x\testpkgids\build\global-autogen" "-ID:\ws\haskell\issues\testpkgids\dist-newstyle\build\x86_64-windows\ghc-8.10.7\testpkgids-0.1.0.0\x\testpkgids\build\testpkgids\testpkgids-tmp" "-ID:\msys64\mingw64\include" "-optP-include" "-optPD:\ws\haskell\issues\testpkgids\dist-newstyle\build\x86_64-windows\ghc-8.10.7\testpkgids-0.1.0.0\x\testpkgids\build\testpkgids\autogen\cabal_macros.h" "-hide-all-packages" "-Wmissing-home-modules" "-no-user-package-db" "-package-db" "D:\cabal\store\ghc-8.10.7\package.db" "-package-db" "D:\ws\haskell\issues\testpkgids\dist-newstyle\packagedb\ghc-8.10.7" "-package-db" "D:\ws\haskell\issues\testpkgids\dist-newstyle\build\x86_64-windows\ghc-8.10.7\testpkgids-0.1.0.0\x\testpkgids\package.conf.inplace" "-package-id" "base-4.14.3.0" "-package-id" "base16-bytest_-1.0.2.0-bbcc9dc783d92d77a328fad00efacf3636a3e0cb" "-XHaskell2010" "app\Main.hs" "-Wall" "-Wunused-packages" "-Werror=unused-packages" "-hide-all-packages"

but ghc somehow is able to get the full clean package name without the hash, i guess it is getting it from the package db:

D:\ws\haskell\issues\testpkgids>ghc-pkg-8.10.7 --package-db=D:\cabal\store\ghc-8.10.7\package.db describe base16-bytestring
name:                 base16-bytestring
version:              1.0.2.0
visibility:           public
id:
    base16-bytest_-1.0.2.0-bbcc9dc783d92d77a328fad00efacf3636a3e0cb
.......

so the package name in the store package.db is the shortened one in macos? i would run the above command to check it

[andreasabel]

On macOS:

$ ghc-pkg-8.10.7 --package-db=$HOME/.cabal/store/ghc-8.10.7/package.db describe base16-bytestring
name:                 base16-bytestring
version:              1.0.2.0
visibility:           public
id:                   bs16-bytstrng-1.0.2.0-692725e8
key:                  bs16-bytstrng-1.0.2.0-692725e8
...

[jneira]

So the unique hypothesis i can think of it is a ghc bug and should be reported if it is not already. //cc @tfausak
To be sure we should get the ghc call made by cabal, but i guess it will not be different re package ids

[tfausak]

I added an unused dependency on ieee just to see what would happen. Here's the relevant output from cabal build --verbose:

/Users/taylor/.ghcup/bin/ghc --make -fbuilding-cabal-package -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi -outputdir /Users/taylor/Local/GitHub/tfausak/monadoc/dist-newstyle/build/aarch64-osx/ghc-9.2.2/monadoc-0.2022.3.27/build -odir /Users/taylor/Local/GitHub/tfausak/monadoc/dist-newstyle/build/aarch64-osx/ghc-9.2.2/monadoc-0.2022.3.27/build -hidir /Users/taylor/Local/GitHub/tfausak/monadoc/dist-newstyle/build/aarch64-osx/ghc-9.2.2/monadoc-0.2022.3.27/build -stubdir /Users/taylor/Local/GitHub/tfausak/monadoc/dist-newstyle/build/aarch64-osx/ghc-9.2.2/monadoc-0.2022.3.27/build -i -i/Users/taylor/Local/GitHub/tfausak/monadoc/dist-newstyle/build/aarch64-osx/ghc-9.2.2/monadoc-0.2022.3.27/build -isource/library -i/Users/taylor/Local/GitHub/tfausak/monadoc/dist-newstyle/build/aarch64-osx/ghc-9.2.2/monadoc-0.2022.3.27/build/autogen -i/Users/taylor/Local/GitHub/tfausak/monadoc/dist-newstyle/build/aarch64-osx/ghc-9.2.2/monadoc-0.2022.3.27/build/global-autogen -I/Users/taylor/Local/GitHub/tfausak/monadoc/dist-newstyle/build/aarch64-osx/ghc-9.2.2/monadoc-0.2022.3.27/build/autogen -I/Users/taylor/Local/GitHub/tfausak/monadoc/dist-newstyle/build/aarch64-osx/ghc-9.2.2/monadoc-0.2022.3.27/build/global-autogen -I/Users/taylor/Local/GitHub/tfausak/monadoc/dist-newstyle/build/aarch64-osx/ghc-9.2.2/monadoc-0.2022.3.27/build -optP-include -optP/Users/taylor/Local/GitHub/tfausak/monadoc/dist-newstyle/build/aarch64-osx/ghc-9.2.2/monadoc-0.2022.3.27/build/autogen/cabal_macros.h -this-unit-id monadoc-0.2022.3.27-inplace -hide-all-packages -Wmissing-home-modules -no-user-package-db -package-db /Users/taylor/.cabal/store/ghc-9.2.2/package.db -package-db /Users/taylor/Local/GitHub/tfausak/monadoc/dist-newstyle/packagedb/ghc-9.2.2 -package-db /Users/taylor/Local/GitHub/tfausak/monadoc/dist-newstyle/build/aarch64-osx/ghc-9.2.2/monadoc-0.2022.3.27/package.conf.inplace -package-id Cbl-3.6.3.0-ece59e6d -package-id sn-2.0.3.0-233c242e -package-id sync-2.2.4-eeb97796 -package-id base-4.16.1.0 -package-id bytestring-0.11.3.0 -package-id containers-0.6.5.1 -package-id cryptnt-0.30-66a8c8a6 -package-id drct-sqlt-2.3.26-53ddf67c -package-id directory-1.3.6.2 -package-id exceptions-0.10.4 -package-id filepath-1.4.2.2 -package-id http-clnt-0.7.11-16be93c9 -package-id http-clnt-tls-0.3.6.1-5a89621f -package-id http-typs-0.12.3-c160083b -package-id -0.7-c9bfa6bf -package-id lcd-2.11.0-4b56e87a -package-id mmry-0.17.0-54c8c04e -package-id mnd-cntrl-1.0.3.1-28593f04 -package-id mtl-2.2.2 -package-id rsrc-pl-0.2.3.2-c3d2b1f6 -package-id sy-0.1.0.1-70e801a8 -package-id sqlt-smpl-0.4.18.0-e98b3617 -package-id stm-2.5.0.2 -package-id tr-0.5.1.1-ee212efb -package-id txt-2.0-021916a5 -package-id time-1.11.1.1 -package-id trnsfrmrs-bs-0.4.6-e302c5e5 -package-id w-3.2.3-c822d6ed -package-id w-xtr-3.1.8-b06c6db6 -package-id wrp-3.3.20-cd32cd5d -package-id wtch-1.0.0.2-16cb42b3 -package-id zlb-0.6.2.3-fba6a3b5 -XHaskell2010 Monadoc.Action.Blob.Upsert Monadoc.Action.Database.Initialize Monadoc.Action.Database.Vacuum Monadoc.Action.HackageIndex.Insert Monadoc.Action.HackageIndex.Process Monadoc.Action.HackageIndex.Update Monadoc.Action.HackageIndex.Upsert Monadoc.Action.HackageUser.Upsert Monadoc.Action.Job.Enqueue Monadoc.Action.Key.SelectLastInsert Monadoc.Action.Package.Upsert Monadoc.Action.PreferredVersions.Upsert Monadoc.Action.Release.Upsert Monadoc.Action.Version.Upsert Monadoc.Class.MonadHttp Monadoc.Class.MonadLog Monadoc.Class.MonadSay Monadoc.Class.MonadSleep Monadoc.Class.MonadSql Monadoc.Class.MonadTime Monadoc.Constant.ContentType Monadoc.Constant.Header Monadoc.Exception.InvalidOption Monadoc.Exception.InvalidSize Monadoc.Exception.MethodNotAllowed Monadoc.Exception.MigrationMismatch Monadoc.Exception.MissingHackageIndex Monadoc.Exception.MissingRowid Monadoc.Exception.MissingSize Monadoc.Exception.ReadFailure Monadoc.Exception.Sick Monadoc.Exception.TrailingBytes Monadoc.Exception.UnexpectedArgument Monadoc.Exception.UnexpectedEntry Monadoc.Exception.UnknownOption Monadoc.Exception.UnknownRoute Monadoc.Extra.DirectSqlite Monadoc.Extra.Witch Monadoc.Handler.AppleTouchIcon.Get Monadoc.Handler.Bootstrap.Get Monadoc.Handler.Favicon.Get Monadoc.Handler.HealthCheck.Get Monadoc.Handler.Home.Get Monadoc.Handler.Manifest.Get Monadoc.Handler.Robots.Get Monadoc.Main Monadoc.Middleware.AddHeaders Monadoc.Middleware.CompressResponses Monadoc.Middleware.HandleExceptions Monadoc.Middleware.LogResponses Monadoc.Model.Blob Monadoc.Model.HackageIndex Monadoc.Model.HackageUser Monadoc.Model.Job Monadoc.Model.Migration Monadoc.Model.Package Monadoc.Model.PreferredVersions Monadoc.Model.Release Monadoc.Model.Version Monadoc.Server.Application Monadoc.Server.Main Monadoc.Server.Middleware Monadoc.Type.App Monadoc.Type.Config Monadoc.Type.Context Monadoc.Type.Flag Monadoc.Type.HackageUserId Monadoc.Type.HackageUserName Monadoc.Type.Hash Monadoc.Type.Key Monadoc.Type.Model Monadoc.Type.PackageName Monadoc.Type.Port Monadoc.Type.Revision Monadoc.Type.Route Monadoc.Type.Severity Monadoc.Type.Status Monadoc.Type.Task Monadoc.Type.VersionNumber Monadoc.Type.VersionRange Monadoc.Vendor.Witch Monadoc.Worker.Main Paths_monadoc -Weverything -Wno-all-missed-specialisations -Wno-implicit-prelude -Wno-missed-specialisations -Wno-missing-deriving-strategies -Wno-missing-export-lists -Wno-missing-exported-signatures -Wno-missing-kind-signatures -Wno-missing-safe-haskell-mode -Wno-prepositive-qualified-module -Wno-safe -Wno-unsafe -hide-all-packages

<no location info>: warning: [-Wunused-packages]
    The following packages were specified via -package or -package-id flags,
    but were not needed for compilation:
      - -0.7-c9bfa6bf

# ghc-pkg --package-db ~/.cabal/store/ghc-9.2.2/package.db describe ieee | head -n 5
name:                 ieee
version:              0.7
visibility:           public
id:                   -0.7-c9bfa6bf
key:                  -0.7-c9bfa6bf

[jneira]

-package-id -0.7-c9bfa6bf, he, that corner case is very interesting but do you agree ghc should show the package name in the error message given it has a working package-id? not sure why it works in windows and no in macos though

[tfausak]

do you agree ghc should show the package name in the error message

Oh yes, absolutely.

[jneira]

ghc issue: https://gitlab.haskell.org/ghc/ghc/-/issues/21307

[andreasabel]

I added an unused dependency on ieee

Brilliant, the best counterexample to the belief that dropping vowels would be a reasonable heuristics.

[jneira]

ghc issue: https://gitlab.haskell.org/ghc/ghc/-/issues/21307

There was an exisiting pr in ghc to improve the error message, showing the package name, version and id: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7883 🎉

not sure why it works in windows and no in macos though

For ghc-9.2.1 the output in windows (it changed from the ghc-8.10.7 one) also was the package id (with the package name shortened):

<no location info>: error: [-Wunused-packages, -Werror=unused-packages]
    The following packages were specified via -package or -package-id flags,
    but were not needed for compilation:
      - base16-bytest_-1.0.2.0-68aa639604c5e056aaaf216872dbbf1cc701905f

[cartazio]

What’s left on this adventure of a ticket ? On the ghc side I see something has been merged, is it in any releases ?

[andreabedini]

If I read the GHC ticket correctly, the fix is going to be in 9.4.1 and not backported.

[jneira]

good news! as each ghc version has a dedicated folder in dist-newstyle and store dir we could fix it conditionally in our code