Handling versioning of platform snaps
tim.sueberkrueb at web.de
Tue Mar 7 18:07:56 UTC 2017
Hey Sergio and Mark,
thanks very much for your help.
After discussing different possible solutions in the team and the
conversation on rocket chat I think that this is probably the best
solution currently possible. We also considered other ways like placing
different library versions in the platform snap but that would be in the
end much more hassle and much more hacky than separating them.
Nevertheless, I still think there could be a better and more convenient
solution for this use case though - at least in theory. Sergio explained
to me that it is not possible to have different versions of the same
snap active, which is - I assume - the main reason why it's impossible
to use different versions of the same runtime/platform snap, while
Flatpak offers this functionality.
I'm not familiar with the technical details of snap. There might be
technical or other reasons why this is not something snap should offer.
But if it is possible, I think it would be very reasonable to allow
snaps to specify a specific version for a content interface plus being
able to have separate versions of the same snap installed as long as
another app depends on it.
This would - if implemented flexible enough - not only benefit our
specific use case but anyone who would like to control versioning of
snaps connecting with the content interface (e.g. a snap that supports
specific plugin versions of some sort of extension).
Again, this is just a suggestion, that I as a user without much
knowledge about the internals find reasonable. This might not fit in the
concept of snaps for a good reason.
Thanks for bearing with me!
> [...] garbage collect all the liriosX-1 snaps that are not connected
to anything (or whatever number makes sense with rollbacks and current
garbage collection rules
I think that would be good to have!
Have a nice day,
On 07.03.2017 14:55, Sergio Schvezov wrote:
> On Tue, 7 Mar 2017 05:06:46 -0800, Mark Shuttleworth wrote:
>> Hi Tim
>> Welcome aboard, and thank you, this is exactly the type of question we
>> want to be solving together on this list.
>> The simplest approach would be to insert a major version/ABI indcation
>> in the platform snap name. Something like lirios3 and lirios4 would be a
>> very explicit way to provided different versions of your libraries. It
>> would have the major benefit that both platform snaps could be installed
>> at the same time, too, enabling a more natural app transition (each app
>> can choose when to hop from 3 to 4) rather than a big-bang flag day for
>> each device. The downside would be the incremental size of having both
>> installed at once during that transition, but we continually see that
>> 'time is more precious than disk space' so giving users a low-friction
>> way to 'just work' is more useful than saving 0.2 GB of their 1 TB disk.
>> It might be worth looking into the linking of apps to particular tracks,
>> but this raises a lot of tricky questions that I suspect would be a
>> swamp with more problems than solutions.
>> Does that sound like a reasonable starting point?
> This is what I suggested during the rocket chat conversations and I agree it is the best way to move forward. What is interesting here is (once there is support to bring in default slot implemetations for an interface), to garbage collect all the liriosX-1 snaps that are not connected to anything (or whatever number makes sense with rollbacks and current garbage collection rules).
More information about the Snapcraft