|
|
|
|
|
by eptcyka
1339 days ago
|
|
> one of the primary points of containerization is the ability to have multiple copies of an application running in parallel using different "application images". One should be able to upgrade (i.e. install a new image in parallel to the old one) without disrupting existing execution environments. Would you like to run a completely new Firefox with a completely new profile whenever you update it? You do know that you can't use the same profile even with the same version of Firefox in two separate Firefox instances concurrently, right? If the updater was aware of snap and snap aware of the application it's updating, you could have a graceful update procedure that serializes the current state and reloads the new container, but that's a lot of hoops to jump through, and the jumping must be coordinated between multiple stakeholders. |
|
1. Install and start Firefox. There is one container and one directory full of profiles.
2. Start the upgrade. This creates a second Firefox installation (container) sharing the same profile directory.
3. Try to run Firefox without quitting the old one. Does nothing because the runtime is smart enough to know that the old one is running. Maybe pop up a message suggesting restarting Firefox.
4. Quit Firefox. Start it again. The new one runs. All the data is still there.
5. The old installation goes away.
The runtime has plenty of flexibility in how to make this work. There could be multiple containers. There could be one container with multiple parallel versions. There could be one container with a staged upgrade that can swap in essentially instantaneously once the container is idle (although this may fall apart on multi-user systems or where the containerized program regularly has multiple running copies of itself at once, e.g. a program like bash).
But the fact that snap apparently has trouble with this seems a bit embarrassing.