snap upgrade hook
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
snapd |
Fix Released
|
High
|
Unassigned | ||
snapd (Ubuntu) |
Fix Released
|
Wishlist
|
Unassigned |
Bug Description
On the a snapcraft ML I was asking about some sort of architectures way to process upgrades.
Somin Fells was so nice to reply with:
"For upgrades there will be a hook at some point in the near future which will notify
when your snap is upgraded and you can perform similar logic like you can do in the maintainer scripts to handle changed formts etc."
But after asking around no one knew about a bug to track that.
Especially for snappy on classic systems that upgrade processing will be needed for quite some packages to be able to be snap'ified.
Eventually the challenge is that regarding packages that need e.g. changed conffiles, templates, schemes, ... we will likely end up with one of:
a) patching the hell out of upstream projects which makes it either hard to be accepted or hard to maintain if ending up in sort of a delta
b) wrap all exposed binaries in wrappers
c) implementing at least a bit of upgrade processing to avoid a/b
I know there is some anxiety to the classic pre/post-inst/rm schema as being complex or error prone. But on the snappy world we don't have to go that far - since we have that nice versioned SNAP_USER_
All that might be needed it a flag for a command that it has to be run automatically after upgrade of a snap. That could do the conversion on the "now new" versioned DATA path of the snap. Every other exposed binary of the snap will just work right away - no need for checkers a la "is it upgraded; no -> call upgrade handler, yes - call actual binary"
Set whishlist as it is a feature