stage-snaps not usable with branches

[Alan Griffiths]

I’m trying to use a branch of a stage snap, but this either isn’t supported, or it doesn’t have the obvious syntax. I have:

  mir-kiosk-x11:
    plugin: nil
    stage-snaps: [mir-kiosk-x11/edge/core18]

But that fails with:

Failed to install or refresh a snap: ‘mir-kiosk-x11’ does not exist or is not available on the desired channel ‘edge/core18’. Use snap info mir-kiosk-x11 to get a list of channels the snap is available on.

On https://forum.snapcraft.io/t/using-branches-with-stage-snaps/20477 it was suggested that to add the track in the channel syntax. But:

  mir-kiosk-x11:
    plugin: nil
    stage-snaps: [mir-kiosk-x11/latest/edge/core18]

results in the same error.

However, both

  snap install mir-kiosk-x11 --channel=edge/core18

and

  snap install mir-kiosk-x11 --channel=latest/edge/core18

work fine.

[John Neffenger (jgneff)]

The problem occurs for Snaps listed under 'build-snaps', too.

I attached the full log file, called 'openjdk_amd64.txt', from my build on Launchpad.

Channel branches seemed a great way to publish the temporary "boot JDK," which is the previous version of the JDK used to build the current version. For example, I wanted to build JDK 13 using the temporary build of JDK 12 that I put on the channel 'latest/stable/jdk-12' as follows:

parts:
  jdk:
    plugin: autotools
    source: https://github.com/openjdk/jdk13u.git
    source-branch: jdk-$SNAPCRAFT_PROJECT_VERSION
    source-depth: 1
    build-snaps:
    - openjdk/latest/stable/jdk-12
    ...

That build fails with:

  "Failed to install or refresh a snap: 'openjdk' does not exist or is not available on the desired channel 'latest/stable/jdk-12'. Use `snap info openjdk` to get a list of channels the snap is available on."

Yet the package can be installed with the command:

$ sudo snap install --channel=latest/stable/jdk-12 openjdk
openjdk (stable/jdk-12) 12.0.2+10 from John Neffenger (jgneff) installed

It looks as if the Snapcraft code is first running the equivalent of the following command to check the store listing before trying to install the Snap:

$ sudo curl --unix-socket /run/snapd.socket "http://localhost/v2/find?name=openjdk&channel=latest/stable/jdk-12"

It doesn't find the branch name in the response, so it doesn't even attempt the installation.

[Michał Sawicz (saviq)]

Still a problem with Snapcraft 4.5.1.

[Michał Sawicz (saviq)]

So the problem is two-fold:
1. Snapd does not return any info for snaps that _only_ have branches
   I believe this is by design, as "closing" channels is meant to "unpublish" a snap.

2. Snapcraft considers the snap invalid, unless the channel maps a non-branched channel:

https://github.com/snapcore/snapcraft/blob/490fceda1f3c4b317c6ccd76c09940d33cc37fda/snapcraft/internal/repo/snaps.py#L172-L173

IMO Snapcraft should not do that check, knowing that the channels returned will not include branches, and instead deal with fallout from `snap download` and/or `snap install`.

[Sergio Schvezov (sergiusens)]

Michał Sawicz <email address hidden> writes:

> So the problem is two-fold:
> 1. Snapd does not return any info for snaps that _only_ have
> branches
> I believe this is by design, as "closing" channels is meant
> to "unpublish" a snap.
>
> 2. Snapcraft considers the snap invalid, unless the channel maps
> a non-
> branched channel:
>
> https://github.com/snapcore/snapcraft/blob/490fceda1f3c4b317c6ccd76c09940d33cc37fda/snapcraft/internal/repo/snaps.py#L172-L173
>
> IMO Snapcraft should not do that check, knowing that the
> channels
> returned will not include branches, and instead deal with
> fallout from
> `snap download` and/or `snap install`.
>

The reason for the check is to allow for advanced grammar to work
(the edge case of using an else statement). We can remove this
behavior for branch statements or just disallow this completely
and cleanly to not have different behaviors.

[Michał Sawicz (saviq)]

> The reason for the check is to allow for advanced grammar to work
> (the edge case of using an else statement). We can remove this
> behavior for branch statements or just disallow this completely
> and cleanly to not have different behaviors.

I do think if branches were disallowed in build/stage snaps, that would really limit their functionality. I suppose you could skip those checks if the channel includes a branch, yeah. May warn that some checks are being skipped.