Investigate issues with mixed repodata

[jezdez]

What happened?

A few recipes have seen repodata files where the subdir doesn't match some of the packages listed in them:

• Update to 3.8.16 conda-forge/python-feedstock#610
• Restore downstream tests with mambabuild conda-forge/jupyter_server-feedstock#111
• conda v23.1.0 conda-forge/conda-feedstock#197

I'm wondering if this is related to conda-index and thought to file a ticket here to investigate.

[jezdez]

/cc @wolfv @dholth @jakirkham

[mbargull]

This comes from openSUSE/libsolv@cc2da2e#diff-2f0af950e6d2249e0340147b80f5b8194de5362f23026ff65cdb65dfa57696aaR314-R320 , i.e., a newly added strict check in libsolv=0.7.23 update.
That check is probably reasonable/good -- but conda-build is not so strict and dumps the to-be-downstream-tested packages in the current subdir.
I'll open an issue on conda-build and -- to get things working for now -- a PR to add a constraint for libsolv in the boa-feedstock (because it's technically an incompatibility between conda-build and libsolv which manifests in plumbing, i.e., boa/conda-mambabuild).

[mbargull]

refs:

• Downstream tests download to wrong subdir (breaks boa+libsolv>=0.7.23) conda-build#4750
• Add workaround run_constrained for libsolv <0.7.23  conda-forge/boa-feedstock#61

[jezdez]

Thanks @mbargull!

[jaimergp]

I am not sure this has to do with this concrete issue at all, but it falls in the same area, so to say. When I was testing if conda-libmamba-solver supported conda-build out of the box, I had to add a few workarounds to make it work.

One of them involves readding noarch to the requested subdirs (see this block). This could imply that the noarch business in conda-build is a bit weird to begin with, and that this issue might be only the tip of a bigger iceberg? 😬

[kenodegard]

Closing since the issue is with conda-build itself (see conda/conda-build#4763)