When you’re putting together a whole system, or a container filesystem mount map, where should you put stuff?
If we’ve succeed, our whole ecosystem is full of path-agnostic stuff, so, technically, it doesn’t matter. You’re free.
... but sometimes conventions are nice anyway. Familiarity. Pre-made choices.
So!
/apps/*
/libs/*
/envs/default/bin
/envs/*/bin
/home/*/envs/*/bin
/bin
/apps/* tree is where we unpack (or mount) applications./libs/* tree is where we unpack (or mount) shared libraries./envs/default/bin directory is a symlink farm, synthesized on the fly. See Wrangling Executable Collections. We’d recommend putting this on your $PATH in your .bashrc (or wherever you set up the shell)./envs/*/bin are symlink farms, too. You can have as many of these as you want./home/*/envs/*/bin tree is yet more symlink farms. The first glob is for usernames; the second is for any environments they want to name, in case there are several. Use this convention on a home desktop or multi-user system (but don’t bother if it’s a single-user environment, or a hermetic build script; there’s no need)./bin tree is optional, but if making bootable media, might be a handy place to put a copy of /envs/default/bin.None of these have to be absolute rooted paths. You can put them all in /warpsys/{apps,envs,libs}/ or in /whatever/{apps,envs,libs}/ and should be just fine and dandy.
It’s recommended that stuff in /apps/* be unpacked/mounted in directories that each contain a hash in the name. This satisfies co-installability. (We intend to build more tools that automate support for doing this, but haven’t yet.) If you’re in a container, though, it’s often fine to get lazy about this.
If you have a /libs/* dir, it’s probably working based on Warpsys Dynamic Library Linking Strategy... so almost certainly that is filled with directories where each contains a hash in the name. It’s necessary for packages to agree on that path naming convention or else things don’t actually get shared too well!