Migrate from core20 to core22

doc
7

Is there a replacement to SNAPCRAFT_BUILD_INFO=y in snapcraft 7? CRAFT_BUILD_INFO does not seem to do the trick.

8

How to have a part with global files with core22? I have a part with patches that stages them and then other parts depend on that part and are using the patches in override-pull, but that no more works, $CRAFT_STAGE doesn’t contain the patches… How is this use-case supposed to work now?

9

And setting LD_LIBRARY_PATH when building a part leads to /bin/bash: line 41: LD_LIBRARY_PATH: unbound variable . This motivated me to create a bug report about regression since Snapcraft 4.0: https://bugs.launchpad.net/snapcraft/+bug/1978859.

10

I’m trying to migrate a snap from core20 to core22. I followed the steps above.

I’m seeing the following:

Bad snapcraft.yaml content:
- extra field 'run-on' not permitted in 'architectures[0]' configuration
- extra field 'filesets' not permitted in 'parts.mypart' configuration

So it looks like the validations for core22 are more strict for these fields?

I should be able to resolve these errors myself, but I wanted to contribute to this migration documentation.

11

It’s not implemented yet. Manifests should be added soon, including annotations.

12

Architectures support is currently being worked on, and the build-on/run-on entries were renamed to build-on/build-to to better match the on/to entries used in advanced grammar (but remember, there is no try).

Fileset definitions will be changed to be more flexible, but you can manually expand them as a workaround until the new implementation is released.

1 Like
13

The recommended way to handle local patches is to apply them directly instead of staging them. You can use places like $CRAFT_PROJECT_DIR/<patches-dir> or snap/local to store the patch files.

14

Patches are for third-party libraries.

15

Ah, I see, it should be accessible from any part… It’s a pity it doesn’t really fit into our workflow, we have a centralized repository with patches for third-party libraries used in multiple projects…

16

One possibility could be to apply the patches prior to building in override-build since it will run after the dependency is staged, but some extra care is needed to make patching not fail as already applied when updating the build, while still handling the error in case of failure applying the patch. Unfortunately it seems that patch(1) doesn’t have an option for that, so some scripting would be required. Or you maybe you can pull the patches from the centralized repository along with the part to be patched?

17

Well, I found another workaround: I copy to $CRAFT_STAGE manually in override-pull, remove the copied folder in override-stage and then stage: [-./*] to avoid snapcraft removing non-existing files

18

Or maybe a git submodule could make all the remote patches appear as local, avoiding more complicated setups.

19

Should this not say “build-for”, not “build-to”?

20

Yes, it’s build-for. Unfortunately it seems that I can’t edit/update the previous post to fix it.

21

@sergiusens Is there an intentional change to the way slots work?

I found that a snap with:

apps:
  confined-shell:
    command-chain:
      - bin/run-shell
    command: usr/local/bin/miriway
    desktop: usr/share/wayland-sessions/confined-shell.desktop
    slots:
      - wayland

Fails to provide a wayland slot, and that I needed to add the slot globally:

slots:
  wayland:
22

I have a project with a file VERSION in the root. With core18 I used

    override-pull: |
      snapcraftctl pull
      snapcraftctl set-version "$(cat VERSION)"

With core22 this gives me

variable 'version' can only be set in a part that adopts external metadata.

But, you give override-<step> and I fail to find what a “part that adopts external metadata” means :frowning: Is there any example of setting the version from a command that reads the version from the sources that works with core22?

23

Just declare adopt-info: <part name> in the yaml top level. adopt-info is explained in the external metadata documentation.

2 Likes
24

Thanks. For those still wondering, <part name> can be a dedicated part, but can also be the name of the part that used to set the version.

25

Is there a way to have both the snapcraft default and append to it? Rather than just override.

In core20, if I do e.g:

environment:
  PATH: ${SNAP}/custom/bin

Then this will be appended to the default $PATH. With the new logic, it’s entirely replaces the default path, and the following doesn’t work.

PATH: ${SNAP}/custom/bin:${PATH}

Where this is more problematic is for $LD_LIBRARY_PATH, because of the common usage of architecture triplets in file paths, you end up having to resort to using a wrapper script to append the value or else the alternative would be hardcoding the value in a way that would probably only work on a single architecture.

Plus, personally, I liked the old way for being cleaner!

26

I’m trying to use the source tag as part of the version for the snap.

I have found nothing in the docs apart for something using git which kind of works. https://snapcraft.io/docs/using-craftctl

This is what I’m trying:

name: polka
base: core22
summary: Polka Snap App
description: A Snap package for the Polka app.
adopt-info: polka-app

grade: stable
confinement: strict

apps:
  polka:
    command: bin/polka

parts:
  polka-app:
    plugin: dump
    source: https://github.com/erik78se/polka.git
    source-tag: v0.9.44
    override-pull: |
      craftctl default
      craftctl set version "$(craftctl get part.polkadot.source-tag)-$(git rev-parse --short HEAD)"

2023-06-21 00:24:09.848 :: 2023-06-20 22:24:07.917 :: error: ‘override-pull’ in part ‘polka-app’ executed an invalid control API call: ‘part.polkadot.source-tag’ is not a valid variable name.

How can I access the source-tag and use it in my version of the snap?