Onedir installation to /opt/saltstack can be a regression

(Note: If it had been this way from the beginning, it would be a design decision made, but changing it now in a mature software package from one release to the next, I consider it a regression. If you disagree, it makes it at least a community help request)

For many years, the salt minion packages installed unter / like most other RPM/Deb packages (/usr/bin, /usr/share, /var. /etc, ...).
We used /opt here for our own applications, and always mount a separate volume for the VMs purpose there, implicitly assuming this is no problem.

Now, moving to 3006.x and the onedir packages, Salt installs itself to /opt/saltstack. (keeping the rest under /etc/salt and /var/lib/salt makes it IMO strictly speakign violating FHS, but I don't want to be that picky).

The base VM images contain the salt minion preinstalled. When our salt states now configure a provisioned VM, prepare the block device, run mkfs and mount that data volume to /opt, salt mounts it "over" itself, breaking the minion.

IMHO, installing the onedir-bring-my-own-python tree e.g. to /usr/share/saltstack or /usr/lib/saltstack instead would have been less of a surprise (to me).

Asking to relocate the onedir tree on subsequent releases for just one random dude (me) on Github ist most probably too much to ask... But as this is about the 5th regression found during upgrading from 3005 to 3006, it's now hard to not at least mention it.

On a more constructive side, Plan B: How could I build custom Deb/RPM packages at least for the minion components where /opt ist kept pristine?

Start by reviewing how the onedir packages place Salt under /opt/saltstack and how the Debian/RPM packages are built. Reproduce the failure by mounting a volume on /opt after the minion is installed, then determine whether the issue's intended outcome is a supported relocation or documented custom package build.