What you can do in the meantime without creating a new content snap is to add a new content interface slot from your qt snap, i.e. something like
slots:
qt513:
interface: content
read:
- /
qt513.1:
interface: content
read:
- /
And then your new snaps that depend on this additional library would be updated as such:
plugs:
qt513.1:
interface: content
target: $SNAP/qt513
default-provider: qt513
such that the qt513.1 plug has a default-provider of the qt513 snap, and in this situation I think what we should do is when updating the mkcron snap, snapd sees that it needs a slot from qt513 that doesn’t exist in the current revision, so it should refresh the qt513 snap first.
In this scenario the key difference being that essentially what the mkcron snap is asking the slot to provide is something more than the default qt513 slot provides, so you need to change the interface name to reflect that something has changed, otherwise (again by design) there is no understanding on snapd’s part that it needs to update anything, because the mkcron snap is asking for a qt513 slot and that slot is being currently provided by the existing snap. There’s no language in the yaml to declare to snapd that something changed which requires an update. The refresh will happen eventually, automatically, but there’s nothing that tells snapd that it needs to do something right now in order to satisfy declared dependencies.
Note I don’t know if what I described above actually happens today or not, I would need to check, but if that scenario doesn’t work, then that is a bug that we should work on fixing. Simply always checking for updates to the content snap isn’t a workable solution for us right now due to the internals of how snap refreshes happen, and while it could be made to do that, that will suffer from other bugs until we have more work done around refresh app awareness and app launch inhibiting AIUI.