[question] Conditional transitive packages

[jasal82]

What is your question?

We have the following problem: Our firmware application builds target an embedded distro that we build with Yocto. The target RFS usually already has an OpenSSL library installed, so we don't want to build it from source (for build time and target image size considerations). However, if the firmware build adds 3rd party packages like grpc from Conan Center as a requirement, then we get an implicit dependency to the OpenSSL package. Our previous workaround was to provide a modified recipe for OpenSSL that detects the target environment, validates the requested version against the available one and enables linking against the system library if necessary, instead of building itself. However, I don't like this solution as it doesn't scale very well. In particular, I want to avoid having to maintain changes to the original recipes.

Ideally, there should be a native solution for this in Conan, but I'm not aware of one. So I was thinking that a proxy package could be a valid workaround. If we export the actual openssl recipe as openssl_upstream and a proxy recipe with auto detection as openssl, then depending on the detected environment the proxy recipe could add openssl_upstream as a dependency to the graph, or not. However, it is not clear to me how to pass the package info through in such a case so that downstream is linked against openssl (as provided by openssl_upstream).

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @jasal82

I think this PR #14871 could be what you are looking for. Please have a look and let us know.

I'd discourage solutions based on detection, but making them imperative, being able to define in your profile that you want the openssl from the system, and not the Conan package one (or be able to replace the upstream openss/xxx package for your custom variant that wraps the system package).

[jasal82]

Hi @memsharded,
the PR seems to be going into the right direction, but it is 2.0 only as far as I can see. I need a workaround for 1.x. I do agree that an imperative approach is much better. What I'm wondering though is how the override in the profile would handle a version mismatch, i.e. if version of system package does not match the one specified in the profile.

[jasal82]

I'm using the following workaround now for 1.x: We rename conanfile.py to conanfile_upstream.py and create our own conanfile.py which imports the original one. Then we inherit from the upstream class and disable source(), build() and package() when a certain option is set. It's not pretty but it works. And it's still somewhat imperative as the consumer has to set the option; there is no auto-detection of sysroot features. After switching to 2.0 we intend to use the functionality implemented in the PR you mentioned earlier.

[memsharded]

These PRs have been merged:

• require-replaces proposal #15136
• New [platform_requires] similar to system-tools, but for all requires #14871

So I'd say that this feature would be addressed by those for 2.0, if you have a workaround for 1.X, then probably we could close this ticket. Feedback about those 2.0 features would be very welcomed.