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: https://github.com/haskell/cabal/blob/ff32a4ea718095af7e1f0f09dee9efb7cea23570/cabal-install/Distribution/Solver/Modular/IndexConversion.hs#L194-L198

It also ignores dependencies on internal libraries: https://github.com/haskell/cabal/blob/ff32a4ea718095af7e1f0f09dee9efb7cea23570/cabal-install/Distribution/Solver/Modular/IndexConversion.hs#L177-L181

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 https://github.com/haskell/cabal/issues/6039, is the one that hampers @michaelpj, his team, users of his software, etc. But is https://github.com/haskell/cabal/issues/6039 required to solve #5413, or is it one of the ways to solve it, the preferred one being https://github.com/haskell/cabal/issues/4087, or do the two overlap somehow and/or perhaps https://github.com/haskell/cabal/issues/4087 solves https://github.com/haskell/cabal/issues/6039 as well?

I'm asking, because I'd like to downgrade the priority of https://github.com/haskell/cabal/issues/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 https://github.com/haskell/cabal/issues/6039 required to solve https://github.com/haskell/cabal/issues/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 https://github.com/haskell/cabal/issues/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 https://github.com/haskell/cabal/issues/2725, just s/executable/internal lib/.

[michaelpj]

I don't understand the landscape here. https://github.com/haskell/cabal/issues/6039 and https://github.com/haskell/cabal/issues/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 https://github.com/haskell/cabal/issues/5413#issuecomment-1285451205. 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.