These articles only give me a very vague idea how it works under the hood. I’m imagining it’s somewhere between a normal package manager and docker. That’s a very wide range of possibilities.
Let’s say I install Firefox.
Does the Firefox bundle also include every file from every dependency of Firefox? Or is it only metadata?
Does each dependency of Firefox get installed in a Firefox folder that houses all of its dependencies? Or are the dependencies somehow shared by different applications?
What if Firefox and some other app have conflicting dependencies? How exactly is that managed?
I’m also curious how user vs default configuration is so well isolated. How does the app know to look for configuration in /usr/share/defaults if the app was written to expect files at /etc?
Is there any documentation that describes any of this in detail?
conflicts are forbidden in Clear Linux OS. Entirely. They do not exist.
firefox is a bad example because we ship the mozilla official build. But e.g. let’s take curl as an example: The curl bundle consists of the curl package, which pulls in various libraries, and includes the lib-openssl bundle. Obviously, this means that the bundle duplicates the libssl.so libraries, but it likely duplicates many system libraries. Since these are shared, no space is wasted. Programs generally do not have their own virtual installation root - all OS software is installed system-wide under /usr.
And yes, dependencies (library, and direct source requirements) are always included in each bundle.
How do you manage to do both of these? What if another bundle comes with a different version of libssl.so? How do you have two versions of the same file? How does each curl know which one to use?
We generally disallow that sort of thing, which avoids a lot of problems. There is often no good reason to have 2 different versions of system libraries around. It’s actually relatively easy for libraries to do this, though, because they have version numbers. There’s definitely exceptions, but never a file-to-file conflict.
We will never have this happen. Our build system detects this and we have to go fix it if it does inadvertently happens.
We wouldn’t have 2 curl’s, but, in the rare case that e.g. something links against libfuse.so.2 and another binary links against libfuse.so.3, then that’s not an actual conflict per se. However, these 2 libraries still both can’t install fuse.pc - one of them needs to be renamed or removed.