Comment 3 for bug 1741628

I think the principal/subordinate discussion might derail this bug. I'd largely regard it is a layer-, boundary- or responsibility-violation if the design of a subordinate charm breaks depending on what the principal charm is installing and where it is installing it.

e.g. in my view:

* Subordinate charms should not write to spaces 'owned' by the principal charm; e.g. the policy example given. Subordinate charms should supply, over a relation, the information necessary to the principal charm to write to the space 'owned' by that charm.

* Subordinate charms should not install packages that are (conceptually) owned by the principal's application; again it should 'ask' that the appropriate functionality is installed IF it has a tight coupling with the main software; I'd regard 'add-on' packages as 'tight', but 'haproxy' as a separate application.

With that in mind, I suspect that quite a few of the concerns raised around snap/deb and locations would go away.

---

Having had more time to reflect on it, the iteration of 'release_pkg' needs to be backwards; starting from the youngest release charm class backwards and testing for release_pkg (or snapped version), and then picking the first one that works.