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.
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.
1 Like
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).
2 Likes
+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.
1 Like
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
I am 
on the new proposal.
1 Like
+1 for the new proposal
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!
2 Likes
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
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
I’ll investigate this next week.
1 Like
Any updates on this issue.
This auto-connection is still not working today. Is this a regression in snapd?
Note: you can test with snap install photoscape --beta. This should auto-connect to the wine-platform-runtime snap.
The snap declaration for wine-platform-runtime has:
{
"allow-auto-connection": [
{
"slot-attributes": {
"content": "wine-runtime"
},
"plug-attributes": {
"content": "$SLOT(content)"
}
}
]
}
but the snap.yaml for photoscape has:
plugs:
wine-platform-runtime:
interface: content
target: $SNAP/wine-runtime
default-provider: wine-platform-runtime
The content interface says: " content (slot and plug) : an arbitrary identifier for content type. Defaults to either local slot name or local plug name for slot/plug definitions respetively.". Since photoscape doesn’t have “content” listed in the plug, it is defaulting to the interface reference, ie “wine-platform-runtime”. Based on the snap declaration, “wine-platform-runtime” != “wine-runtime”, so it is not a candidate for auto-connection.
Photoscape needs to adjust the plugs to be either:
plugs:
wine-platform-runtime:
interface: content
content: wine-runtime
target: $SNAP/wine-runtime
default-provider: wine-platform-runtime
or:
plugs:
wine-runtime:
interface: content
target: $SNAP/wine-runtime
default-provider: wine-platform-runtime
then it should work.
1 Like
The photoscape snap in the beta channel has the following plug declaration in meta/snap.yaml:
wine-5-stable:
interface: content
target: $SNAP/wine-platform
default-provider: wine-platform-5-stable
wine-runtime:
interface: content
target: $SNAP/wine-runtime
default-provider: wine-platform-runtime
This seems to be what you propose.
However, when I install it, it does not get auto-connected.
I pushed a version with differently-named plugs in the edge channel to try out other names, so that might be what you were looking at.
Hrm, I did install --beta, but I looked in the store at the snap.yaml, which was pointing to edge. I can confirm that the beta snap has:
wine-runtime:
interface: content
target: $SNAP/wine-runtime
default-provider: wine-platform-runtime
and that it did not auto-connect.
Out of curiosity, I updated photoscape’s snap declaration to have:
"content": {
"allow-auto-connection": [
{
"slot-attributes": {
"content": "wine-runtime"
},
"plug-attributes": {
"content": "$SLOT(content)"
},
"slots-per-plug": "*"
},
{
"slot-attributes": {
"content": "gtk-3-themes"
},
"plug-attributes": {
"content": "$SLOT(content)"
},
"slots-per-plug": "*"
},
{
"slot-attributes": {
"content": "icon-themes"
},
"plug-attributes": {
"content": "$SLOT(content)"
},
"slots-per-plug": "*"
},
{
"slot-attributes": {
"content": "sound-themes"
},
"plug-attributes": {
"content": "$SLOT(content)"
},
"slots-per-plug": "*"
},
{
"slot-attributes": {
"content": "gtk-2-themes"
},
"plug-attributes": {
"content": "$SLOT(content)"
},
"slots-per-plug": "*"
},
{
"slot-attributes": {
"content": "gnome-3-28-1804"
},
"plug-attributes": {
"content": "$SLOT(content)"
},
"slots-per-plug": "*"
}
]
}
and found that it did auto-connect, but based on Plug/slot declaration rules: greedy plugs it seemed like it should not have made a difference since there weren’t multiple “candidate pairs” AFAICS (I’ve since removed that temporary snap declaration).
@pedronis, can you comment? photoscape --beta has this in snap.yaml:
plugs:
gnome-3-28-1804:
interface: content
target: $SNAP/gnome-platform
default-provider: gnome-3-28-1804
gtk-3-themes:
interface: content
target: $SNAP/data-dir/themes
default-provider: gtk-common-themes
icon-themes:
interface: content
target: $SNAP/data-dir/icons
default-provider: gtk-common-themes
sound-themes:
interface: content
target: $SNAP/data-dir/sounds
default-provider: gtk-common-themes
wine-5-stable:
interface: content
target: $SNAP/wine-platform
default-provider: wine-platform-5-stable
wine-runtime:
interface: content
target: $SNAP/wine-runtime
default-provider: wine-platform-runtime
gtk-themes-common has this snap declaration in slots:
"content": {
"allow-auto-connection": [
{
"slot-attributes": {
"content": "gtk-3-themes"
},
"plug-attributes": {
"content": "$SLOT(content)"
}
},
{
"slot-attributes": {
"content": "icon-themes"
},
"plug-attributes": {
"content": "$SLOT(content)"
}
},
{
"slot-attributes": {
"content": "sound-themes"
},
"plug-attributes": {
"content": "$SLOT(content)"
}
},
{
"slot-attributes": {
"content": "gtk-2-themes"
},
"plug-attributes": {
"content": "$SLOT(content)"
}
}
]
}
gnome-3-28-1804 has this in its snap declaration for slots:
"content": {
"allow-auto-connection": [
{
"slot-attributes": {
"content": "gnome-3-28-1804"
},
"plug-attributes": {
"content": "$SLOT(content)"
}
}
]
}
wine-platform-runtime has this in its snap declaration for plugs (I initially said slots):
{
"content": {
"allow-auto-connection": [
{
"slot-attributes": {
"content": "wine-runtime"
},
"plug-attributes": {
"content": "$SLOT(content)"
}
}
]
}
}
1 Like
Ok, I found the issue (@pedronis, nevermind my previous question).
The wine-platform-runtime snap was not setup like gtk-themes-common and gnome-3-28-1804 like I claimed a long time ago. It was using the snap declaration in its plugs, not its slots. I adjusted the snap declaration for wine-platform-runtime to have in its slots (with nothing in its plugs):
{
"content": {
"allow-auto-connection": [
{
"slot-attributes": {
"content": "wine-runtime"
},
"plug-attributes": {
"content": "$SLOT(content)"
}
}
]
}
}
then I removed photoscape and wine-platform-runtime from the machine, did a snap refresh to make sure I had all the updated snap declarations and then did:
$ sudo snap install photoscape --beta
photoscape (beta) 3.7 from Merlijn Sebrechts installed
$ snap connections photoscape
Interface Plug Slot Notes
content[gnome-3-28-1804] photoscape:gnome-3-28-1804 gnome-3-28-1804:gnome-3-28-1804 -
content[gtk-3-themes] photoscape:gtk-3-themes gtk-common-themes:gtk-3-themes -
content[icon-themes] photoscape:icon-themes gtk-common-themes:icon-themes -
content[sound-themes] photoscape:sound-themes gtk-common-themes:sound-themes -
content photoscape:wine-5-stable - -
content[wine-runtime] photoscape:wine-runtime wine-platform-runtime:wine-runtime -
desktop photoscape:desktop :desktop -
desktop-legacy photoscape:desktop-legacy :desktop-legacy -
gsettings photoscape:gsettings :gsettings -
home photoscape:home :home -
network photoscape:network :network -
network-bind photoscape:network-bind :network-bind -
wayland photoscape:wayland :wayland -
x11 photoscape:x11 :x11 -
and wine-runtime did auto-connect. Sorry for noise, but glad it is now fixed.
2 Likes