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: libQt5HttpServer.so.5: cannot open shared object file: No such file or directory
Which is basically a missing library issue caused due to the absence of libQt5HttpServer.so.5 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.
->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.
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.
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.
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.