I appreciate that Qubes allows me to totally separate the threats of various apps and I use it extensively by having a separate Template VM for each software that I use (about a dozen or so) all based on the same debian base template. Now I’m running low on disk space and I realize that most space is just wasted by these templates which are all around 7 GB which seems to be mostly system files which are identical for all these various templates. Is there a way to use my disk space more conservatively?
It feel almost as if there should be some dynamically loaded base image structure that is not copied across all Template VMs over and over again.
The other upside of such a dynamically loaded base image besides space would be speed & frequency of upgrades which increases security as well: Currently, it seems the Qubes update manager only checks for upgrades after having launched an app VM. But when I’m already using an App VM I’m many times too busy (and frankly, it might already be too late if there’s zero day exploits) to do the upgrade on the spot. Thus, it would be super useful to only have to upgrade on base Template that is then immediately inherited into all my template and app VMs.
Anyway, to answer your question: No, chained templates are not supported. However, you have other options, like minimal templates, disposable templates, app qubes that you treat as sub-templates, bind-dirs, and so on. (For example, if you just need to install a small program in one app qube, you could just use rc.local to install it at every startup instead of having a whole separate template for that app qube.)
Just a thought here, but I don’t know how practical it would be for updates.
Start with your minimal template and create a seperate block device from your storage pool for each software that you must keep seperate.
During AppVM startup use rc.local to mount that block device over top of /usr/local/* to make just that software available in that specific VM. You can even mount it read only for normal runtime to make it resistant to hacking and then write a salt script to roll through each software to pick up any updates using a different VM in which that block device is mounted rw.
It all depends on whether your apps can be installed in an alternate path or not.
Instead of /usr/local there is also docker containers, flatpacks, Snap, etc. One minimal template with the proper services running in the AppVM needed to support a container system would then allow installing a specific software container from a user supplied block device at runtime.