[bug] Overridden requirement still builds original requirement and scrambles options

Environment Details (include every applicable attribute)

• Operating System+version: docker ubuntu:jammy-20220531
• Compiler+version:
• Conan version: pip3 install conan --upgrade
• Python version: python3 jammy

dockerfile

FROM ubuntu:jammy-20220531 RUN apt-get update && apt-get install -y
autoconf
g++
make
pkg-config
python3-pip
&& apt-get clean RUN pip3 install conan --upgrade

Steps to reproduce (Include if Applicable)

conan install -b missing -b outdated -b cascade conanfile.txt

where conanfile has

[requires] openssl/3.0.3 poco/1.11.3

[build_requires] cmake/3.23.2

[options] openssl:shared=False openssl:no_gost=True openssl:no_asm=True openssl:no_idea=True openssl:no_mdc2=True openssl:no_rc5=True poco:shared=False poco:enable_encodings=True poco:enable_xml=True poco:enable_json=True poco:enable_util=True poco:enable_zip=True poco:enable_net=True poco:enable_crypto=True poco:enable_netssl=True poco:enable_apacheconnector=False poco:enable_cppparser=False poco:enable_data=False poco:enable_data_mysql=False poco:enable_data_odbc=False poco:enable_data_postgresql=False poco:enable_data_sqlite=False poco:enable_jwt=False poco:enable_mongodb=False poco:enable_pdf=False poco:enable_pagecompiler=False poco:enable_pagecompiler_file2page=False poco:enable_pocodoc=False poco:enable_redis=False poco:enable_sevenzip=False poco:enable_activerecord=False

Logs (Executed commands with output) (Include/Attach if Applicable)

WARN: poco/1.11.3: requirement openssl/1.1.1o overridden by your conanfile to openssl/3.0.3 bzip2/1.0.8: Package is up to date expat/2.4.8: Package is up to date zlib/1.2.12: Package is up to date pcre/8.45: Package is up to date poco/1.11.3: Forced build from source ERROR: openssl/1.1.1o: option ‘no_fips’ doesn’t exist Possible options are [‘no_threads’, ‘shared’, ‘fPIC’, ‘no_asm’, ‘enable_weak_ssl_ciphers’, ‘386’, ‘no_stdio’, ‘no_tests’, ‘no_sse2’, ‘no_bf’, ‘no_cast’, ‘no_des’, ‘no_dh’, ‘no_dsa’, ‘no_hmac’, ‘no_md5’, ‘no_mdc2’, ‘no_rc2’, ‘no_rsa’, ‘no_sha’, ‘no_async’, ‘no_dso’, ‘no_aria’, ‘no_blake2’, ‘no_camellia’, ‘no_chacha’, ‘no_cms’, ‘no_comp’, ‘no_ct’, ‘no_deprecated’, ‘no_dgram’, ‘no_engine’, ‘no_filenames’, ‘no_gost’, ‘no_idea’, ‘no_md4’, ‘no_ocsp’, ‘no_pinshared’, ‘no_rmd160’, ‘no_sm2’, ‘no_sm3’, ‘no_sm4’, ‘no_srp’, ‘no_srtp’, ‘no_ssl’, ‘no_ts’, ‘no_whirlpool’, ‘no_ec’, ‘no_ecdh’, ‘no_ecdsa’, ‘no_rfc3779’, ‘no_seed’, ‘no_sock’, ‘no_ssl3’, ‘no_tls1’, ‘openssldir’]

Also built similar config with additional requirements on Windows without issue

The initial trigger might be the POCO requirements() ? but why doesn’t it stay overridden?

    if self.options.enable_netssl or self.options.enable_crypto or \
       self.options.get_safe("enable_jwt"):
        self.requires("openssl/1.1.1o")

Hopefully I’m confused and you can correct me

[memsharded]

When I do that, I guess I should also set the recipe user/channel on the modified recipes so that they do not mix with the official conancenter builds, right?

It depends, but it can be problematic if mixing your own variants with some of the conancenter ones that haven’t been taken ownership. That is, either you fork and replace the requires = "...." of the packages you use to point to your user/channel variant, or it is better to leave them without user/channel.

I wouldn’t care about the openssl version of some build tool, but the actual problem is that my product also uses OpenSSL in its requires, and we are using openssl v3. This was working so far. Recently, I tried adding a new library from conancentral. Apparantly, this new library has set cmake as a build_tools dependency, and this broke my build.

Thanks for the clarification, it makes sense, I thought it was only a dependency for CMake.

[memsharded]

Yes, the issue is that the options evaluated in the “host” context, the “requires”, is later affecting the options of the same dependency (even different version) of the “build” context, the tool_requires (build_requires). It is clearly a bug, I have already tried a couple of different approaches, but I can’t find a way that wouldn’t break other legit uses…

The reason you might be seeing a different conflict message, is if using the “build” and “host” context. You can try forcing it by applying a -s:b os=Linux (or any --profile:build or any other --settings:build)