Hey Mark,
thank you for explaining this, the reasons are clearer to me now.
> 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.
You're right, that's a good point. The only difference is that it's slightly
harder to maintain because instead of maintaining different versions of
one package
we need to maintain different versions of different packages. And for each
new version, a new name has to be registered which is probably going to
be harder to automate.
Nevertheless, I agree, it is not such a big deal.
As for Liri, we're now discussing different options inside of our team.
I'm generally very happy with the developer experience of snapcraft and
the user experience of snap and I'm really looking forward to see snaps
running on Ubuntu phones & tablets.
Thanks again for taking your time to help us!
All the best,
Tim
On 08.03.2017 13:48, Mark Shuttleworth wrote:
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).
--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
