Specialize parts based on architecture

snapcraft
1

Is there any way to specialize the variables of a part based on the architecture?

The specific use-case here is to create a snap from prebuilt upstream binaries, where a different source file (and hence different source-checksum) would be required for each architecture.

1 Like
2 
parts:
  foo:
    source:
      on amd64: url-to-amd64-source
      on i386: url-to-i386-source
    source-checksum:
      on amd64: checksum-for-amd64
      on i386: checksum-for-i386

Does that not work?

3 Likes
3

D’oh! That’s indeed what I was thinking of, but had forgotten the syntax, and didn’t find by searching (I see now that it’s in the Advanced grammar docs section). Thanks very much!

1 Like
4

To be fair, unless you know it’s called “Advanced grammar” it’s a touch hard to find. I think we’d be better off making that page a little different with some examples and words like “architecture specific”.
What do you think @degville?

1 Like
5

That said, it doesn’t seem to work for source-checksum:

    source-checksum:
    - on amd64: "sha3_512/a407dc067b82c5f6ac325dd1be4d5718c05149fffe3d2de82f02b536fa388e669499d45ce8e0f65bf049b3e33ba2a103fdee77fbd5e427e4da9d0bbee6ec8b33"

… results in the following error:

Issues while validating snapcraft.yaml: The 'parts/ldc/source-checksum' property does not match the required schema: [OrderedDict([('on amd64', 'sha3_512/a407dc067b82c5f6ac325dd1be4d5718c05149fffe3d2de82f02b536fa388e669499d45ce8e0f65bf049b3e33ba2a103fdee77fbd5e427e4da9d0bbee6ec8b33')])] is not of type 'string'
6

Agreed. I think it would be a great help if this syntax was referenced from the https://snapcraft.io/docs/architectures page, which is where I went looking for it (and got confused when I couldn’t find it).

7

Booo! Sounds like we need to cast a spell of invocation :mage: @cjp256 - can you help here?

1 Like
8

Yea, it’s quite an “Ouch!” oversight, isn’t it? :laughing: Looking forward to seeing the magic being worked.

TBH I’m not sure I even understand why on ... specializations are restricted to only a subset of vars – I presume just in order to help the developers avoid having to deal with debugging all the potential combinatorical variations that users could come up with?

9

I think this is a really good idea - an overhaul of our Advanced Grammar doc(s) has been on my target list for a long time. It’s difficult to understand, difficult to find and missing some important pieces, but I’ll try to prioritise it.

3 Likes
10

I believe @sergiusens is interested in expanding the advanced grammar to work across the entire (most?) of the YAML.

At minimum, there is clearly a strong case for it to work with source-checksum as well @joseph.wakeling.

2 Likes
11

That’s great to hear. Thanks everyone for being so responsive – it helped me move forward today with a number of things that had been blocked for a while.

12

Cross-posting here because I missed this thread when I started mine.

Long story short, I’m trying to do exactly this: Repackage a deb app as a snap. So I need to lconsume either a x86 or arm64 deb as source, depending on the target. The suggested snippet, which is also what I tried, seems to indicate snapcraft to use different sources when building on different architectures instead of for different architecturs. So it works as long as you build you x86 snap on an x86 host and the arm64 snap under a arm64 host.

13

OK the Advanced Grammar hint was gold. It seems like the to keyword is what I needed!

parts:
  my-app:
    source:
      - on amd64 to amd64: http://redacted/x86.deb
      - on amd64 to arm64: http://redacted/arm64.deb
    source-type: deb
    plugin: dump
1 Like
14

You meant ?

parts:
  my-app:
    source:
      - on amd64 to amd64: http://redacted/x86.deb
      - on amd64 to arm64: http://redacted/arm64.deb
    source-type: deb
    plugin: dump
1 Like