Handling versioning of platform snaps

[Mark Shuttleworth]

Snaps have a much stronger sense of identity. They *own* /snap/foo and
that means you can build a much more predictable and reliable view of
their behavior. Versioning is a key part of the snap story, it gives the
user and the publiisher of the software a really *great* way to describe
what they are releasing or what they are conuming on any particular
device. The upstreams and the users that I have talked to generally say
they *love* it.

The fact that we know exactly where a snap is allows for rich interplay
between snaps, like the way snaps can use the core snap, or other snaps
through content interfaces.

However, all of these things also required that we choose not to mount
snaps in arbitrary locations. That ends up driving the requirement that
you have administrative rights on a device if you want to change the set
of installed snaps, and also that you can only have one active version
at a time.

In the case of libraries and frameworks, you don't have to worry about
persistent data that can or cannot be shared between the two versions.
You would need to know the two paths of the two versions *anyway* in
order to use them. THere is no semantic difference in your code between
/snap/foo-4.7 and snap/foo/4.7 so your own app code isn't going to be
more complex one way or the other.

Mark

On 07/03/17 10:07, Tim Süberkrüb wrote:
> 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,
>
> Tim
>
> 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).
>>
>
>