I tried to install volta, a node/yarn/npm version and toolchain manager, but the install script does an openssl version check by parsing the output from the openssl executable. There’s a workaround (not using the script), but it got me thinking: why is Silverblue different than other distros in this regard?
The issue thread with Volta, if anyone is interested in this: Installer fails on Fedora Silverblue · Issue #962 · volta-cli/volta · GitHub
You probably want to do that inside of a toolbox container.
Thanks, but the problem isn’t that it breaks, I don’t really care, I actually prefer installing tools like these from tarballs anyway. I’m just curious why most distros have an openssl executable, and silverblue doesn’t. It would also be relevant info to pass along to the Volta devs, so they can either fix their script or at least add a caveat to the readme.
The idea behind Silverblue is to provide just enough of an OS to run applications in containers (via Flatpak, toolbox or podman directly).
From what I gathered, Volta is a development tool and toolbox has been made just for that initially: running development tools on Silverblue so you don’t have to install all your development tools and their dependencies on the base system and run them inside a container instead.
You don’t have to explain silverblue to me, I’ve been here for years. 
Volta is a single precompiled executable that installs to your home directory, even if you use toolbox it will be still there outside of it. The only reason to use toolbox would be if it needed a build dependency, which it doesn’t because it’s precompiled. The only reason the (unnecessary) installer fails is because it assumes every distro has an openssl executable.
The only thing I’m wondering about is this: why is there no openssl executable when other distros have it. There is an openssl libs package that is part of base image, so it’s not like openssl isn’t part of silverblue, there’s just no executable. That’s it, that’s the only thing I wonder about.
I’m sorry this came out that way as I’m just trying to give context to answer your question. Silverblue only ships what’s needed for the applications included in the OS and apparently nothing relies on the openssl binary itself, only on the libraries so there is apparently no reason to include the binary by default in the image.
Yes, your program will be installed in your home directory that is shared with toolboxes but this is an external program and Silverblue can not include dependencies for all external programs that you might want to install on your system. Toolbox are made just for that, running anything that requires more build or runtime dependencies to be installed than what’s available in the base image.
If you think the binary should be included in the base image, you can open an issue in the Silverblue issue tracker: Issues · fedora-silverblue/issue-tracker · GitHub
Thanks. I did some digging. Seems it’s split into two packages: openssl (utilities) and openssl-libs (the actual library), where the utils package contains the executable. I’m guessing it’s because of minimalism that it’s not included in Silverblue (or the base toolbox image, for that matter, although there you have dnf). I’ve told the Volta devs, maybe they’ll write a more robust check. Or maybe just make the script fail with a custom error message if the user is on Silverblue.
Anyway, I don’t think this warrants a bug report, I’m guessing it’s by design.