conanfile.txt执行conan install时libjpeg重复提供报错如何解决

这个报错的触发原因是：gdal/3.4.3的默认依赖链会拉取libjpeg/9d，和你在requires里显式声明的libjpeg-turbo/2.0.5都声明提供libjpeg功能，Conan无法自动选定使用哪个实现，因此抛出冲突。

不需要切换到conanfile.py，以下两种方案都可以仅通过修改conanfile.txt解决问题：

方案1：全局替换libjpeg依赖（推荐，适配所有依赖链场景） #

在conanfile.txt中新增[replace_requires]配置段，将依赖树中所有对libjpeg的引用统一替换为你指定的libjpeg-turbo版本，从根源消除重复提供同功能的问题。
修改后的完整conanfile.txt内容如下：

[requires]
libexif/0.6.23
sdl/2.0.20
nlohmann_json/3.10.5 
yaml-cpp/0.6.3
gdal/3.4.3
openssl/1.1.1o
libjpeg-turbo/2.0.5

[replace_requires]
libjpeg/*: libjpeg-turbo/2.0.5

[generators]
cmake_find_package
cmake_paths

配置规则libjpeg/*: libjpeg-turbo/2.0.5表示匹配所有版本的libjpeg依赖，全部替换为libjpeg-turbo/2.0.5，不管是gdal还是其他间接依赖引入的libjpeg都会被替换，不会再出现冲突。

方案2：单独指定gdal的jpeg实现 #

如果不想做全局替换，也可以通过选项单独配置gdal使用libjpeg-turbo作为jpeg依赖，新增[options]段即可：

[requires]
libexif/0.6.23
sdl/2.0.20
nlohmann_json/3.10.5 
yaml-cpp/0.6.3
gdal/3.4.3
openssl/1.1.1o
libjpeg-turbo/2.0.5

[options]
gdal:with_jpeg=libjpeg-turbo

[generators]
cmake_find_package
cmake_paths

*注意：如果后续新增的其他依赖也隐式引入了libjpeg，这个方案会再次触发冲突，优先选择方案1稳定性更高。

修改完成后重新执行conan install命令即可正常完成依赖安装，不需要编写conanfile.py相关逻辑。

内容的提问来源于stack exchange，提问作者user15476592