please allow deleting specific (old) architecture snaps

Bug #1907108 reported by Jamie Strandboge
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Snap Store Server

Bug Description

This was reported here: with further discussion here:

In the case of the forum reporter, they pushed a revision for i386 but then decided they do not want to support that (eg, after switching to core20).

I have a similar case where I published an arch 'all' snap years ago when initially developing the ufw snap but then moved to arch-specific snaps. As a result, 'snapcraft promote' always wants to promote this 'all' snap and 'all' is listed as a suggestion in

Partial workaround: close the channel and then populate it with only the revisions of the architectures you want. This seems to work reasonably well for 'snapcraft promote', but the<snap>/releases will still suggest the old arch.

Revision history for this message
Brad Warren (bradmwarren) wrote :
Revision history for this message
Alex Haydock (alexhaydock) wrote :

This seems to still be an issue and the workaround (closing the channel and re-populating) is very cumbersome.

I have multiple Snaps where i386 is now deprecated by the move to core20 and where I would prefer to delete the entire architecture from the Store if possible.

To add another use-case for a "delete architecture" feature - for a lot of my Snaps, I built on all architectures while first learning Snapcraft because why not? Over time, I've experienced build failures as apps and dependencies have updated, as expected, but I haven't got the time nor hardware to devote to debugging the ones on the more obscure architectures. Given the nature of the apps in question, I don't think I'll be disappointing anyone by deprecating these architectures for my Snaps. I doubt anyone is installing Raincat on an IBM Mainframe. (Though if anyone is then please do speak up because I'd love to meet you!)

There's a good chance that nobody will ever try to install my Snap packages on the deprecated architectures anyway, but if they did, what they would end up with is a (probably very) outdated package that's not guaranteed to work, and which I can't provide support for if the user asks.

A way of resolving this would be great!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers