Add metadata describing the architectures that a snap can be built for

Bug #1533713 reported by Colin Watson
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Confirmed
Wishlist
Pat McGowan
Snapcraft
Fix Released
Wishlist
Unassigned

Bug Description

<cjwatson> sergiusens: I'm pretty confused about how the "architectures" field in a snapcraft.yaml is meant to work. It seems to override the architectures of the generated snap package, not specify which architectures the snap might be built for - is that right?
<sergiusens> cjwatson, architectures in snapcraft.yaml should probably just go away; it is only there since people wanted it on special request (using prebuilt binaries and manually constructing a fat package).
<sergiusens> but yes, it is an override, not a "built this for" :-/
<cjwatson> sergiusens: Have you put any thought into metadata that describes the architectures that the source code for a snap can be built for? It would be useful for the LP/store interaction.
<cjwatson> sergiusens: debs have this for a reason ;-)
<sergiusens> cjwatson, can you log a bug, I agree, but I'll forget https://bugs.launchpad.net/snapcraft :-)

To elaborate on this: it would be useful to be able to make a single build request to Launchpad which would build the snap for all architectures it supports. At the moment you can configure this in Launchpad, but it really belongs with the snap's metadata instead. Each individual (non-fat) snap that comes out of this should still have just a single architecture in its metadata.

As with debs, there should be a value that indicates that the snap is portable code that you can build anywhere reasonable (like "Architecture: any"). It may also be useful to have a value that indicates that the snap only needs to be built once and will then consist of architecture-independent code that can be used on any architecture (like "Architecture: all"), although I don't know how common that situation is given Snappy's approach of bundling everything.

Tags: personal
Revision history for this message
Kyle Fazzari (kyrofa) wrote :

> At the moment you can configure this in Launchpad, but it really belongs with the snap's metadata instead.

Are you saying that Launchpad actually supports building .snaps? Or am I just reading my hopefulness into your comment?

Changed in snapcraft:
status: New → Triaged
importance: Undecided → Low
Kyle Fazzari (kyrofa)
Changed in snapcraft:
importance: Low → Wishlist
Revision history for this message
Colin Watson (cjwatson) wrote : Re: [Bug 1533713] Re: Add metadata describing the architectures that a snap can be built for

On Wed, Jan 20, 2016 at 10:38:53PM -0000, Kyle Fazzari wrote:
> Are you saying that Launchpad actually supports building .snaps? Or am I
> just reading my hopefulness into your comment?

http://blog.launchpad.net/general/launchpad-news-august-2015

Changed in snapcraft:
milestone: none → 2.8
Changed in snapcraft:
milestone: 2.8 → none
Revision history for this message
Sergio Schvezov (sergiusens) wrote :

I've raised a couple of keywords to make use of this here https://lists.ubuntu.com/archives/snappy-app-devel/2016-April/000654.html

There are follow ups in that thread.

Revision history for this message
Pat McGowan (pat-mcgowan) wrote :

With the advent of content interfaces I find the need for an All or Any type build to be helpful.
Case 1 - I have a QML app using the ubuntu-app-platform interface where a single snap could run on a number of architectures.
Case 2 - I am simply sharing content via a snap that provides data for other snaps and is platform independent.

Changed in canonical-devices-system-image:
assignee: nobody → Pat McGowan (pat-mcgowan)
importance: Undecided → Wishlist
milestone: none → p2
status: New → Confirmed
tags: added: personal
Revision history for this message
Sergio Schvezov (sergiusens) wrote :

architecture support to define how a ci system is to be setup to build has been defined and released in 2018

Changed in snapcraft:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.