Will this break backward compatibility? What do we intend to happen when a snap which is declaring aliases is installed on a snapd where this ability has been removed?
It will not break backwards compatibility for automatic aliases because the new snap-declaration language will be in place by the time we release a snapd with the new mechanism. This will be put in a different field, so we don’t break previous snapds that still rely on the old language.
That said, it will break backwards compatibility mainly in cases where we have manual aliases in place, because the cost of handling all the possible permutations of these cases doesn’t seem worth the cost of development of that specific migration path. There’s still time to change that decision if there’s strong disagreement or data proving otherwise, but I’d prefer to keep that path otherwise.
To make sure I understand: currently, individual snaps can declare aliases for their apps, but such aliases are not automatically enabled upon installation unless the snap-declaration assertion says so. Correct? Assuming I understand that, then what you say makes sense.
“manual aliases” being when the user runs snap alias themselves?
So say I maintain a snap that declares aliases, but has nothing in its assertion to automatically enable them. Let’s also say that the snapd which stops recognizing the declared aliases was just installed in an update.
- If a user has my snap installed but done nothing with
snap alias, the only affect of this update is that the user will need to enable aliases in another way (or perhaps thesnap aliascommand changes somewhat). Correct? - If the user has my snap installed and has enabled the aliases manually via
snap alias, these aliases will be removed by this update. Correct?
Right. For the typical case of people just using automatic aliases, the migration won’t be perceived and the only breakage will be in the behavior of the alias command.
As of right now, yes, this is correct.
Alright. Please let us know when we should deprecate aliases in snapcraft.
Work on this is proceeding, this related PRs were already merged:
https://github.com/snapcore/snapd/pull/3021
https://github.com/snapcore/snapd/pull/3030
https://github.com/snapcore/snapd/pull/3029
1 Like
The next PR has been updated to follow the last decisions with aliases state for a snap stored in its SnapState:
1 Like
This PR needs a 2nd review. It this marked blocked pending having the timeline for 2.24 vs 2.25 clarified: once it’s merged we cannot make a stable release until the new “snap alias”/“snap unalias” are implemented:
@pedronis As mentioned there, can’t say it looks good since this is just the disabling step, but hopefully a solid step towards having the new semantics in place.
PR with tasks and handlers (with temporary “-v2” names for now) to implement most of the new semantics for install/refresh:
https://github.com/snapcore/snapd/pull/3087
another PR is coming soon switching over install/refresh etc and with migration code.
@niemeyer I now also proposed a PR that does the main switch to the new tasks and semantics and introduces the Ensure transition to v2 aliases:
@niemeyer based on discussion and review feedback I created:
https://github.com/snapcore/snapd/pull/3155
and then merged it to simplify things in:
https://github.com/snapcore/snapd/pull/3087
they are both ready for review
1 Like
I merged #3155
as I mentioned #3087 can be re-reviewed,
and this one should be reviewable as well (it builds on top of #3087 but it’s relatively orthogonal changes and deletions on top of that)
@niemeyer I tried to answer the comments, but indeed they can/will be covered by follow ups
also there was an issue with the recent changes and #3137 which should be fixed now
I merged
https://github.com/snapcore/snapd/pull/3082
which means alias commands will be broken until we land the new implementations for 2.25
@niemeyer all the following PRs are now ready for review or at least a first pass review (they build on each other though):
https://github.com/snapcore/snapd/pull/3137
https://github.com/snapcore/snapd/pull/3191
https://github.com/snapcore/snapd/pull/3192
they have TODOs as needed in their descriptions, I also progressed quite a bit on a branch to implement "snap prefer " but that one is not quite ready for review.
Now there’s also a PR ready for review giving a try at “snap prefer”:
@niemeyer seems we need a way to spell “snap unalias SNAP” if we in the end think that conflating “snap unalias ALIAS” and this should not be mixed to avoid confusion.
“snap prefer SNAP” is the positive action here (but also touches other snaps), and “unprefer” anyway is strange…