You can add your files anywhere inside your snap, but other snaps will not be able to see those files unless they are exposed, and consumed, by a content interface, or the snap is used as a base snap like core currently is for many apps. Base snaps are tightly controlled in the public store, but if you have a brand store I believe you have more leeway for publishing.
Note also that not every application on your system will necessarily be using the same base snap. On my system, I have snaps using core as a base (built from Ubuntu 16.04) and others using core18 as a base (built from Ubuntu 18.04).
The core base snap provides OpenSSL 1.0.2g, while core18 ships both versions 1.0.2n and 1.1.1 (with most apps linked against the newer version). It’s highly likely that there will be a core20 base next year, increasing the number of versions further.
So I guess the real question is: what do you want to achieve by replacing the OpenSSL library?
We want to have tested FIPS certifications changes in openssl along with the latest.
I quoted openssl as an example. we might have database client used by multiple snaps and would like to share it so that size of snaps are less
you’re rite, how do applications know the /usr/lib/x86_64-linux-gnu path.
when I ran snap run --shell app.name and try to see the environment, I don’t find the path to the openssl engines lib path.
can you help me to understand how this achieved.
When you launch a snap app, it is called through a wrapper that sets up a sandbox for the app. Part of this involves the use of “mount namespaces”, which allows different processes to see different views of the file system.
The biggest change is using the contents of the snap’s base snap (either core or core18) as the root of the file system. You can see what these root file systems look like by exploring /snap/core/current/ or /snap/core18/current/.