I think you missed my point. Updating the menu with qvm-sync-appmenus isn’t merely unwieldy in salt. It does not work at all. The call has no effect whatsoever. So I have to do that part, at the very least, in a script. (And I got really, really tired of having to “manually” fix my menus and desktop shortcuts every time after running salt to regenerate qubes.)
You and I did go through a discussion regarding disposable templates (I don’t recall all of the details) and were able to resolve one case, but the resolution broke other cases. I ended up…again in a script…having to either set the default menu items or menu items in a certain sequence, depending on whether a qube was a template, an (ordinary) appvm, an appvm that was a dvm template, or a named dvm, all after the qube was otherwise set up. If I didn’t handle the cases differently from each other, something would “break” and I’d have desktop shortcuts that didn’t function and/or a dvm template that didn’t show up in the menu properly.
As for the other issues, I know I brought up the issue of a qube being cloned by dom0 before that qube ran the states to configure itself, and that conversation sort of trailed off at that point (after someone told me how to combine states in a TLS file, but his advice was irrelevant to my situation and you and I both recognized that).
So returning to that: is it possible to make a state on target dom0 require a state on target some-template-VM, which means a state in a different sls file in a different “environment”?
If so I could certainly do more things with tls files and fewer things with bash scripts. (As of right now, just running updates is the closest I come to running pure salt; there’s no order dependency there and I use the bash script simply to assemble the rather unwieldy salt command line for me.)