Recommended approach for classic/non-classic versions

Hello,

I look after the snap for duplicity (a backup program that needs to read and write to arbitrary locations) that has already received classic confinement approval.

While classic confinement is required for equivalent functionality to the deb version, we could make a more confined version that would be sufficient for some use-cases (particularly once the system-backup interface exists: https://github.com/snapcore/snapd/pull/6436 ).

What is the recommended approach for distributing both a confined and classic snap (e.g. separate snaps, different tracks)?

Is it possible for a snap to identify what confinement it is running within? I am imagining steering people towards the confined version by default and then giving a tasteful error message if somebody is using the application in a way that needs them to install the classic version instead.

1 Like

WRT your last question, a snap can always look at its own snap.yaml (so something as crude as grep confinement "$SNAP/meta/snap.yaml" might be all you need).

2 Likes

This is a relatively new concept and people have been discussing doing thing via tracks over in: Track request(classic) for the tree snap

1 Like