Solver tries to solve for unneeded internal libs:

[phadej]

cabal-version: 2.2
name: bug
version: 0

library
  build-depends:
    , cabal-plan ^>=0.3.0.0
    , base-orphans ^>= 0.8

cabal-plan has an internal lib, which depends on base-orphans ^>= 0.7, but main-library doesn't depend on that component. There's also an automatic flag, which could turn out the executable component (which depends on the internal lib).

EDIT even explicitly saying cabal new-build --constraint='cabal-plan -exe' doesn't help.

[grayjay]

I don't think the solver has any support for disabling components or tracking intra-package dependencies yet. It combines all of the libraries and executables' dependencies here:

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

Lines 194 to 198 in ff32a4e

	flagged_deps
	= concatMap (\ds -> conv ComponentLib libBuildInfo initDR ds) (maybeToList mlib)
	++ concatMap (\(nm, ds) -> conv (ComponentSubLib nm) libBuildInfo initDR ds) sub_libs
	++ concatMap (\(nm, ds) -> conv (ComponentFLib nm) foreignLibBuildInfo initDR ds) flibs
	++ concatMap (\(nm, ds) -> conv (ComponentExe nm) buildInfo initDR ds) exes

It also ignores dependencies on internal libraries:

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

Lines 177 to 181 in ff32a4e

	-- | We have to be careful to filter out dependencies on
	-- internal libraries, since they don't refer to real packages
	-- and thus cannot actually be solved over. We'll do this
	-- by creating a set of package names which are "internal"
	-- and dropping them as we convert.

#4087 will need to address this issue.

[gbaz]

@Mikolaj this ticket hasn't seen activity in a few years. Any particular circumstances that would cause bumping priority at this time?

[Mikolaj]

@gbaz: it's related to #6039 that users are keen to see solved. Also I'd love to learn what's the status of this one and of #6039.

[grayjay]

@Mikolaj This issue depends on #6039, but I think that the best way to fix it is by finishing implementing the per-component dependency solving in #4087, which would allow the solver to enable individual components. Is there a reason that this specific part is higher priority now?

[michaelpj]

I think you're right, yes, that per-component dependency solving subsumes this. The specific issue where this was biting us was like this:

• Package A has a main library component A:L and an executable component A:E
• A:E depends on a package Z which has a problematic system dependency S
• Package B depends on A:L
• Attempting to build B without S installed gives a solver pkg-config error about S, even though cabal will not even try to build Z.

I think that's a manifestation of this particular ticket, but I agree that the per-component dependency solving should fix it.

[Mikolaj]

I'm a bit lost. I understand this here issue (#5413), not #6039, is the one that hampers @michaelpj, his team, users of his software, etc. But is #6039 required to solve #5413, or is it one of the ways to solve it, the preferred one being #4087, or do the two overlap somehow and/or perhaps #4087 solves #6039 as well?

I'm asking, because I'd like to downgrade the priority of #6039 based on how long ago users expressed interest and how it's related to other tickets. (Of course these are not the only indicators of priority, but given that we are understaffed right now, the cooperation or outright PR creation by users is super important.)

[phadej]

But is #6039 required to solve #5413,

I think @grayjay tries to say that there is no known easier&faster way to solve either of these than to solve them in principal way by implementing #4087

If it helps, #6039 and #5413 should be listed as related issues in #4087, among ones already there.
E.g. this issue is very much the same as #2725, just s/executable/internal lib/.

[michaelpj]

I don't understand the landscape here. #6039 and #4087 look similar to me as an outsider, but I'm unsure if there's actually a significant difference.

This issue probably does not represent the root cause: I think @grayjay is right to say that the root cause is one of those two issues. But this issue accurately describes the issue that I see, which is why I posted here.

[grayjay]

I realized that the relationship between the issues is more complex than I described:

#4087: This issue describes a large design change to the solver that would fix many issues related to components, including this one. It is partially implemented.

#5413: This issue focuses on the solver incorrectly requiring dependencies from unused internal libraries. The problem is more general though and affects all types of components, including the scenario with executables in #5413 (comment). I think that the best solution is to implement the part of #4087 that relates to enabling individual components.

#6039: This issue is specifically about the multiple public libraries feature. It overlaps with #4087 but also deals with problems that only affect multilibs, such as the visibility field and allowing one package to depend on multiple installed components from another package. Some parts of #6039 are necessary to implement #5413.