Can you please run make config-rebuild and commit the changes it makes?

Can you please run make config-rebuild and commit the changes it makes?

Done.

Wondering if building (mulled) containers needs to be adapted accordingly?

The reason we added this channel is to have a fallback for anything that is too ugly to get into bioconda. Do we still have this fear? If so we should fix/update the EMBOSS package instead of removing the channel.

I understand .. seems reasonable. But with the current channel order its not a fallback, but the default -- isn't it?

Maybe a bit more background. I was trying to install rnaquast (https://github.com/bioconda/bioconda-recipes/blob/master/recipes/rnaquast/meta.yaml) and for some reason it used emboss 5.0.0. from the IUC channel instead of a newer one from bioconda. So I was thinking that the IUC package causes the problems.

• EMBOSS 5.0.0 its already in bioconda https://github.com/bioconda/bioconda-recipes/tree/master/recipes/emboss/5.0.0 and the recipe seems more or less identical

• ucsc tools seems to be a meta package ..

• pglite seems not in conda except for IUC channel

So I see that removing the cannel seems not the best idea at the moment. Maybe a different channel priority would be an idea. channel-priority: disabled (i.e. --no-channel-priority) would be an option since then IUC packages are only considered in case of ties.

We could remove the EMBOSS package from the IUC channel, without changing anything?
I think our thinking to include iuc at the front was so that we can overwrite packages from other channels if really needed. But again we tried to be prepared for a case that never occured. So if you all want to drop it, I'm ok with it.

We could remove the EMBOSS package from the IUC channel, without changing anything?

I think this would help for my problem. But to be 100% sure one would need to test he emboss tools with the bioconda package.

I think our thinking to include iuc at the front was so that we can overwrite packages from other channels if really needed. But again we tried to be prepared for a case that never occured. So if you all want to drop it, I'm ok with it.

Since I'm not sure about the other packages .. the safer change would be to change the channel priority... or?

channel_priority (ChannelPriority)
Accepts values of 'strict', 'flexible', and 'disabled'. The default
value is 'flexible'. With strict channel priority, packages in lower
priority channels are not considered if a package with the same name
appears in a higher priority channel. With flexible channel priority,
the solver may reach into lower priority channels to fulfill
dependencies, rather than raising an unsatisfiable error. With channel
priority disabled, package version takes precedence, and the
configured priority of channels is used only to break ties. ...

It's easy enough to add the channel back with a lower priority, should the need arise.