Make the cabal-install solver multilibs-aware

[fgaz]

The Cabal part is done, but cabal-install's solver is not aware of the multiple public libraries feature yet, leading to late errors and issues like #6038

[23Skidoo]

/cc @grayjay @kosmikus -- How hard do you think this would be to implement?

[grayjay]

I think this would be pretty straightforward, at least for source packages, because it could be implemented similarly to enforcing build tool dependencies. The visibility field could probably be implemented similarly to the current handling of unbuildable components. I have a few questions about how visibility should behave, though.

• Should the solver enforce visibility now? I wasn't sure if the comments about disabling the visibility field in Prevent dependency on private library #5848 applied here.
• Should the solver just check the visibility fields in Library and InstalledPackageInfo? Can the main library be private?

There may be an issue with enforcing visibility for installed packages, because there is a hack where the solver treats installed internal libraries as separate packages with munged names (

cabal/cabal-install/Distribution/Solver/Modular/IndexConversion.hs

Lines 106 to 131 in 5f57d4d

	-- Note [Index conversion with internal libraries]
	-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	-- Something very interesting happens when we have internal libraries
	-- in our index. In this case, we maybe have p-0.1, which itself
	-- depends on the internal library p-internal ALSO from p-0.1.
	-- Here's the danger:
	--
	-- - If we treat both of these packages as having PN "p",
	-- then the solver will try to pick one or the other,
	-- but never both.
	--
	-- - If we drop the internal packages, now p-0.1 has a
	-- dangling dependency on an "installed" package we know
	-- nothing about. Oops.
	--
	-- An expedient hack is to put p-internal into cabal-install's
	-- index as a MUNGED package name, so that it doesn't conflict
	-- with anyone else (except other instances of itself). But
	-- yet, we ought NOT to say that PNs in the solver are munged
	-- package names, because they're not; for source packages,
	-- we really will never see munged package names.
	--
	-- The tension here is that the installed package index is actually
	-- per library, but the solver is per package. We need to smooth
	-- it over, and munging the package names is a pretty good way to
	-- do it.

). I'm not sure how difficult it will be to distinguish between inter- and intra-package dependencies.

[fgaz]

Should the solver enforce visibility now? I wasn't sure if the comments about disabling the visibility field in #5848 applied here.

Yes. In #5848 we're talking about disabling it at the syntax level, but internally it's still used

Should the solver just check the visibility fields in Library and InstalledPackageInfo? Can the main library be private?

Yes and no, but I'll have to check the second one.

[grayjay]

@fgaz Thanks. I made a PR (#6047), but it only checks the visibility of source packages so far. It reads the libVisibility field for all libraries, though I can easily change it to only check sub-libraries if that is the correct behavior.