Content snap wont upgrade on install of new app which is based in it

Hi, This is a serious issue about content-snaps and the way they are used.

I recently gone through a case where my newly published app won’t run cause the content snap that it is based on did not update to the latest stable before I installed and opened my app.

Explanation :

I have lots of apps in store which are based on same content snap in this case (qt513), Recently I published an update to my content snap qt513 which include new libraries (required to run new application I was about to publish) in both stable and edge channel.

I published my new app mkcron last night. And installed it from store. While launching I got the following error: mkcron: error while loading shared libraries: cannot open shared object file: No such file or directory Which is basically a missing library issue caused due to the absence of in the qt513 content snap.

While this library is included in the upgrade to my content snap that I did two days back.

What should be happening:

Before installing any snap app snapd should check for update of the content snap at least in stable channel. This should be done to ensure that all required content snaps are up to date as desired by developer/publisher of application.

Snap --version

snap 2.44.3+20.04
snapd 2.44.3+20.04
series 16
Ubuntu 20.04
kernel 5.4.0-29-generic


I understand why you might want this to happen but this was not in the design for the content snap system. The content interface has an attribute that defines the “API promise” of the content that other snaps subscribe to. While cumbersome, to achieve what you want you would have to update that field on both snaps to achieve the desired result.


Thanks for update on this,

How I can do this ?

My situation is:

->Thousands of users are there who have qt513 snap already installed already since they installed my other apps before.
-> I update my qt513 snap which contains runtime required by my applications.
-> Those thousands of users install my newly published application which requires a library that according to me and snapcraft definition is present in the content and will be made available to my app by it.

But is not seem to be happening right now, since users who did not update to the latest version of qt513 (content snap) will fail to run the new app.
This could lead to the disreputing of my app and user may give bad ratings in store or may write a bad review on the internet. Or may blame snap package management technology for all this.

I did saw this reflecting on many applications (of other publishers) reviews in-app store (snap-store GUI) where people rating apps one star or two cause their app failed to launch. (Please have a look at this issue too)

Am sure am not the only one utilizing content snaps in my snaps, gnome do this, kde do this and there are many more. This could happen to everyone.


gnome uses different snaps and different content labels for API versions. We could possibly do something sensible for same snap but different slot with new label. Same snap, same label there is no reason for snapd to update the snap. The snap is violating the design assumptions.

You mean i need to create a new content snap for my new app since it require one new library ? which i could add to older one easily. Just because snapd wont upgrade content snap which it should do acc. to design.

I understand your anxiety to build a working system.

This statement is not true. There is no such design. The design is that snapd will connect any compatible content, as defined by the content: ... attribute. The default provider is downloaded automatically on demand, to satisfy the requirement. There is no other promise that the system gives you.

I have looked at the source code and I cannot find a quick and easy way out of the problem that does not involve creating a new content snap.

1 Like

My proposal to solve any kind of such issue would be checking for updates of content snap before installing app snap, i don’t think upgrading content snap will harm user in any way. Since the developer of content snap wants user to upgrade it to use his new app.
There can be prompt asking user asking about the upgrade. where if he choose to refuse he simply won’t able to install new app.
That’s all am trying to say.

1 Like

I honestly think that’s a sensible thing to do but I cannot promise any decisions or timelines. We’re trying to wrap up a big chunk of work now.

1 Like

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

    interface: content
      - /
    interface: content
      - /

And then your new snaps that depend on this additional library would be updated as such:

    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.

1 Like

We never trigger refreshes for prerequisites ATM, but I agree that this scenario (new label qt513.1) is within the scope of the current design, and triggering a refresh would be correct behavior. So I agree it’s a bug that we ought to fix.


We never trigger refreshes for prerequisites ATM, but I agree that this scenario (new label qt513.1) is within the scope of the current design, and triggering a refresh would be correct behavior. So I agree it’s a bug that we ought to fix.

the correct behavior in this scenario, to try to update the default-provider if it’s already installed but the content label is not offered on the system yet, has been implemented in 2.53 now.

1 Like