About the maintenance efforts of libsolv and our patches

[jaimergp]

Through the conversations in https://github.com/conda-forge/openmpi-feedstock/issues/153, we have come across a few cases where libsolv fails to find the "expected" solution. TLDR: Despite build numbers and track features being adjusted, the low prio variants are selected.

The investigations lead to code that is not part of libsolv itself, but only in our builds because of the patches in the recipe. Particularly this one, which maps (roughly) to this unmerged PR. In that PR, the maintainer also mention related work in an unmerged branch that could be useful.

My questions are several but in a way related:

• @beckermr points out that we effectively maintaining a fork of libsolv in the feedstock for three years now. I think it might be time to either push on @wolfv's PRs for upstream inclusion, or, if impossible, recognize the fork nature of this recipe and create a libsolv-conda fork that we build and test as any other project. This dependency is too central to the ecosystem to rely on patches.
• If the above becomes true, we can test that trackfeature branch and see if it solves the openmpi issue described at the beginning of the issue.
• There are also some more PRs contributed by conda community members that could improve performance or improve matchspec compatibility, to name a couple.

Thoughts @conda-forge/libsolv?

[JohanMabille]

Given the history where PRs are very long to get in, when they do, I would be in favor of recognizing the fork. I'm not blaming the maintainers of libsolv, I understand they have a huge community of users and this comes with strong constraints. But we also have ours, and it would completely make sense for me to be able to work independently on the solver codebase.

We also plan to develop a modern native SAT solver (similar to resolvo) to replace libsolv in mamba (but of course this will take time).

[beckermr]

Can we come to some agreement with upstream to put our changes behind preprocessor guards, ensure that we do not touch external functions, and have them allow us to merge changes faster?

This would seem to me to be mutually agreeable and better than us having a fork.

[beckermr]

There is honestly no way we on our own have the effort to maintain the entire codebase. I get that it is easier to build something in a fork rather than deal with more people, but I really don't think a fork is sustainable.

[jezdez]

I would strongly prefer upstreaming the patches instead of continuing to fork libsolv, especially since we know how hard it is to maintain one.

I would like to understand better why it has taken the maintainer long to merge PRs, if it's a matter of funding and/or time/staffing, or whatever else, and then work to resolve these problems.

I am worried about us as an ecosystem taking shortcuts for fundamental parts of our stack, and instead of considering fixing the tech debt (I know, ironic coming from me), we're going back to a clean slate and rather start from scratch again. Seems not sustainable.

[jakirkham]

Could we setup a meeting with the libsolv team to discuss? Or invite them to an existing meeting? Maybe we can hash out a plan