is it possible to have two snap names point to the same snap ID?
For example, a vendor comes and asks us to rename the coconut snap to papaya, but lots of things on the Internet continue to say snap install coconut even after the vendor updated its own documentation.
This would actually be super useful when trying to upstream snaps, as well. Right now there’s a bit of friction where a developer might register a namespaced snap name <upstream name>-<developer name> (since transferring snap IDs was historically hard), and then the snap gets pretty popular. I’m in this situation now. I’m not quite sure how to move the snap upstream because the upstream developer would obviously want to register <upstream name>. This means they don’t obtain my users, and I also need to figure out some way to tell my users to use the upstream snap without leaving them in a lurch. Being able to point multiple names at the same snap ID seems like a good transition path to actual snap renames.
This could be solved by renaming your snap and then transferring it, but we currently have work to do on both snapd and the store to support renames.
Indeed, which is why in my mind this makes for a good transition path.
@kyrofa If you mean aliasing snap names (as in Evan’s example, not be confused with the current snap aliases feature) I don’t think we’ll do that as it has some large implications for the system design. Better for us to just implement renames when we can get to it.
(editing to clarify about “alias” term)
Is there a spec for how renames would work? Surely the issue that @evan raised is that old documentation will continue to use the old name, and he wants that documentation to continue to work - e.g.- snap install oldname ought to transparently install the newname snap.
I’m not necessarily suggesting that we should implement such an alias feature - I agree that it’s likely to have some unforeseen impact on the rest of the system, but I can’t see how renaming a snap solves this problem.
Regards,
It doesn’t. I kinda derailed this conversation with my comment, I’m sorry. I mean to say that having multiple snap names pointing to the same snap ID (as Evan is proposing) makes renaming less necessary, since it solves some of the same problems.
Ahhhh, understood.
In general, this feels to me like a solution in search of a problem. If we have concrete examples of where this is really needed then I guess we can re-open this investigation. It seems like something that’s at most going to be needed in very rare cases however.
I have a specific ISV example of where having two snap names reference the same snap ID would be of real value.
I’ve been talking with the Microsoft Visual Studio Code team for some time. They were initially resistant to publishing a snap. As part of the campaign to popularise snaps as the way to distribute Electron apps on Linux I published the vscode snap. Since doing so the team at Microsoft have decided to publish a snap themselves and registered the snap name code, which I now understand is how they referer to Microsoft Visual Studio Code in shorthand in all their documentation.
In due course I will transfer ownership of the vscode snap to Microsoft and they will start publishing the code snap. The thousands of existing installs of vscode will need a means of migrating to the code snap and anyone reading the existing documentation on 3rd party sites that state snap install vscode will need to continue to work.
I hope that descirbes a real world use case sufficiently.
Your case describes the need to handle renames properly, rather than to have a snap with multiple names. Having a snap with multiple names is very confusing and will probably never be supported. What we should do, perhaps in the short term, is to implement support for erroring in a more helpful way, explaining that the rename took place. This will teach people about the fact, and puts everybody back onto the same page again.
Complete renames, in which snapd itself transitions a snap from one name to the other, will be supported eventually and is the only reason why we have snap IDs at all.
We already have code to detect renames and error in this case, though I think it might need a review that it works as needed especially because we moved around things quite a bit in snapstate since it was written and it’s not exercized in spread.
I meant more helpful errors to the user when trying to install the old snap. Something like
$ snap install foo
error: snap "foo" was renamed "bar"
what if the renamed snap is on an ubuntu core system and is something essential … (kernel or gadget).
do we only operate by snap-id in that case so that the system stays functional ? or do we actually not upgrade such a snap anymore.
As mentioned above complete renames in which snapd itself transitions a snap from one name to the other, will be supported eventually. That means it’s not supported yet.