Auto connections of wine-base-stable, wine-base-devel and wine-base-staging


#1

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.

Currently consumer snaps are using this.

plugs:
  wine-platform-plug:
    content: wine-base-stable
    interface: content
    target: $SNAP/wine-platform
    default-provider: wine-platform

apps:
  foo:
   command: bar
   plugs:
    - wine-platform-plug

Proposed changes after merge

plugs:
  wine-base-stable:
    interface: content
    target: $SNAP/wine-platform
    default-provider: wine-platform:wine-base-stable

apps:
  foo:
   command: bar
   plugs:
    - wine-base-stable

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.

wine-platform:wine-base-stable notepad3,notepad3:wine-platform-plug

here only notepad3 is connected with proposed changes and users can not disconnect wine-platform-plug after new update snap.


#2

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.


#3
  • 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 script or script+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.


#4

This suggests to me wine-base-3-stable vs wine-base-4-stable. These could be shipped in the same or separate snaps.

Ok, that’s what I thought. Thank you for confirming. As such, I don’t think -1604 or similar is required (but see above comment).


#5

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.


#6

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.


#7

Current updated request

  • wine-base-3-stable (old stable)
  • wine-base-stable (current stable)
  • wine-base-devel (current devel)
  • wine-base-staging (current staging)

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.


#8

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).


#9

+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.


#10

New proposal after considering changes suggested so I’ve broke the wine-platform snap into 5 different snaps with following my actual request

  • wine-platform-runtime

This snap only contains wine required pkgs and does not have wine.

  • wine-platform-3-stable
  • wine-platform-4-stable
  • wine-platform-4-devel
  • wine-platform-4-staging

These snaps will only have a single wine as per version and nothing else.

Rerequesting auto connections for

  • wine-runtime
  • wine-3-stable
  • wine-4-stable
  • wine-4-devel
  • wine-4-staging

#11

I am :+1: on the new proposal.


#12

+1 for the new proposal


#13

2 votes for, 0 against. Granted the following:

  • auto-connect of wine-runtime to the wine-platform-runtime snap
  • auto-connect of wine-3-stable to the wine-platform-3-stable snap
  • auto-connect of wine-4-stable to the wine-platform-4-stable snap
  • auto-connect of wine-4-devel to the wine-platform-4-devel snap
  • auto-connect of wine-4-staging to the wine-platform-4-staging snap

Thanks for making the updates!


#14

Does this still applies with granted auto connections.

Since the reason of this request was to allow other snap publishers to use these content snaps for their wine snaps.

Snap from a different snap publisher fails.

snap install --edge mikrotik-winbox

icon-themes auto connects fine
wine-runtime fails
wine-3-stable fails


#15

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


#16

I’ll investigate this next week.


#17

Any updates on this issue.