@jdstrand @sergiusens That’s indeed the intended (or at least agreed) outcome. The option was deprecated a long time ago, and right now we have snapcraft injecting “grade: stable” in snap.yaml, which is the worst of all possibilities since we lose the knowledge of what the person said completely. It’s time to start rejecting snaps that don’t specify grade. We won’t make snapcraft refuse to produce them, as that would be a breaking change, but the store may refuse to take them in.
With that said, I suggest we phase the feature in so we can anticipate the consequences: first thing is to get snapcraft to not inject the option, and then make the store accept them. This will give us visibility on what will be rejected next. Then we can start to reject them and ask for grade to be specified on the way into the store.
No, this will be in separate files, perhaps meta/i18n/<lang>.yaml. Format to be defined still.
Packing it in snap.yaml / snapcraft.yaml would make it messy and hard to collaborate on.
I don’t see how the second question is different from the first one, though.
@jamesh Not in the sprint, but we did talk about it a very long time ago, and there was even a PR for it.
The main issue with supporting polkit is that it doesn’t actually solve the problem, I think. Even if we implement support for it, we still need to be able to tell which user that is so that the store may allow access to their personal snaps, and paid content they’ve previously purchased. So polkit would need to happen in addition to the macaroon-based authentication, in which case why not solving both problems with a single mechanism?