Encode flag setting in InstalledPackageInfo?

[bgamari]

Describe the bug
In haskell/text#487 we noticed that there is no robust way to force cabal-install to reinstall a pre-existing library when flags are changed. In this case this means that there is no way for a user to enable the text package's simdutf flag if GHC ships with the flag disabled.

This is due to the fact that the only information Cabal has about pre-existing packages is that which is recorded in InstalledPackageInfo. As InstalledPackageInfo includes no knowledge of flags, cabal-install merely assumes that the pre-existing package's flag setting is compatible with that requested by the user.

For this reason, it seems reasonable to encode flag settings in InstalledPackageInfo. As, to my eyes, flags seem to be a slightly "higher-level" concern that the other InstalledPackageInfo fields (which encode precisely the information needed by GHC to compile and link against the package), I suspect this information best belongs in a "non-normative" IPI field. That is perhaps we introduce the convention that any field starting with X- will be ignored by GHC. This would allow Cabal to encode flag settings in an X-Flag-Setting field while keeping separate concerns separate and making it clear that GHC will not depend upon this knowledge.

[phadej]

In haskell/text#487 we noticed that there is no robust way to force cabal-install to reinstall a pre-existing library when flags are changed.

There are no robust way to force cabal-install to reinstall pre-existing library at all. E.g. if you want to amend ghc-options, or about anything actually.

Should one record ghc-options too in IPI? I think not.

IMO, a robust solution is to:

• Have a way to force reinstalling a pre-existing library (possibly at the exact same version). We have constraints: pkg installed, we should have an opposite.
• Given that cabal-install is able to do the above, then when requested a setting (flags, ghc-options, etc) which it doesn't know for sure, it reinstalls the package.