Currently wine-platform snap does not provide ootb auto connection to wine-base-xyz which is really bad view for new snap user which just want to point and click app icon and expects it to just run without another interaction.
I think this change would break consumer snaps which are depended on previous changes so it would require new changes if this is merged.
If snap connected to previous plug is updated to the snap having proposed changes does work however it did not disconnect wine-platform-plug upon updating.
If you’re concerned about auto-connections for consumers that come from arbitrary publishers, this still wouldn’t address the problem of not auto-connecting because the content snaps only auto-connect by default when the publisher matches. You could pursue a snap declaration to globally connect these interfaces. You are on the right track naming them wine-base-XXX, but I think to be considered for a global auto-connect, we’d need to understand at least two things:
is stable vs staging vs devel sufficient forever? I suspect that these might need to change to wine versions so that whenever stable updates, it doesn’t break existing snaps that only worked with the old stable
how sensitive are consumers (plug) of the content interface to the provider’s (slot) build environment? Ie, if the slot content is built on (the future) Ubuntu 20.04, is a consuming snap that was built on Ubuntu 16.04 expected to work flawlessly?
This is all in reference to the template we came up with for globally auto-connected content snaps that the content attribute must conforms: <thing>-<thing version>-<build env version>, eg, gnome-3-26-1604 denotes this is a gnome 3.26 content snap that was built on Ubuntu 16.04. There is some latitude as to what the <thing version> and <build env version> should be, but they should be clear to other developers that plugs your content.
I think current proposed base suffix should suffice which follows winehq deb pkg version divisions of wine. Right now I’m using old stable wine 3.x.x and not the current stable 4.x which breaks handful of my snaps though I could solve that issue with introducing the 4th wine base for keeping old-stable as wine-base-old-stable though it will fat up content snap I’m keeping it as is for that reason.
And for version num on base name as these change time to time could again require request for auto-connect, I’m rather using these on content snap version as (3.0.4-4.6) 3.x.x as stable, 4.x as devel and staging these are same.
Not that much sensitive as wine consumer snaps merely contain a scriptorscript+windows program/game executable files with no Linux pkgs staged so content snap does the heavy lifting part. Consumer snaps should be built easily on any version build environment and should work fine.
I think the change for old stable wine-base-3-stable is fine by me, as for version 4.x . I think leaving it as wine-base-stable is good choice because in future suppose wine have stable 5.x then it would again require auto connection and it will also create three different bases for wine stable versions if we stick with wine-base-x-stable for new stable versions.
I’m sorry, I found this unclear. Are you saying this is what you would like:
wine-base-3-stable (old stable)
wine-base-4-stable (current stable)
wine-base-N-stable (future stables)
If so, this makes a lot of sense to me since everything is explicit, developers know what they are getting and there aren’t any major release migrations that might break people.
So with above changes only my broken snaps on wine 4.x will only need new base migration changes for old stable and other snaps that were using stable base will be auto migrated to current stable base with no user action requiring if we leave it as wine-base-stable instead of wine-base-4-stable.
So if we want to using this format for all the N of stable releases then future wine-platform snap will be going to be really fatty guy.
wine-base-N-stable (future stables)
So using my updated request format wine-platform snap will be only keeping old-stable wine version not all N of releases future stables.
Keeping in mind that there is a contract between the providing snap and the consuming snap for all interfaces and with content interfaces which are globally auto-connected in particular, the contract is that the slot side must never, ever, break the plugging snap which is why we have rules regarding naming. Since we know that wine-base-stable (4.x) breaks 3.x in certain cases, I’m very uncomfortable with granting ‘stable’, ‘devel’ and ‘staging’ without the version in the name. While ‘stable’, ‘devel’ and ‘staging’ seems to be the upstream approach, it is known that these will eventually roll forward which is counter to how things work in the snap ecosystem.
I am therefore -1 on the current request and suggest instead:
wine-base-3-stable (old stable)
wine-base-4-stable (current stable)
wine-base-N-devel (current devel)
wine-base-N-staging (current staging)
With this, there shouldn’t be any user action, but there would be publisher action to adjust the plugging snaps to use newer wine bases (which IMO is completely appropriate since they are the only ones who can properly verify their snaps against the new base).
I’m open to other options based on your feedback and feedback from other @reviewers (note, I tried thinking through a combination of tracks and content names, but this didn’t seem to address not breaking plugging snaps). Also, IME, there is no reason why all these wine bases need be in a single monolithic wine-platform snap (eg, consider the gnome content snaps which are separate: gnome-3-26-1604 and gnome-3-28-1804) and perhaps it makes sense to break this up into wine-platform-3, wine-platform-4, wine-platform-N, etc, but using the above content names in them (this is of course up to you).
+1 on @jdstrand suggestion on the naming convention.
The idea to use stable for current stable is good , but if there’s a change in wine+1 compared to wine-current, then this will break existing snaps. I also think having separate platforms as individual snaps would work well - smaller footprint, more modular, allows finer control over games-to-wine pairing.
I can confirm the behavior you are seeing, but I don’t see why it is failing. The snap.yaml in the wine-platform-runtime is setup like gtk-common-themes and likewise, the snap declaration for wine-platform-runtime is setup like gtk-icon-themes. Perhaps this is a recent regression? cc @zyga-snapd
on the new proposal.