Default-provider in slots and plugs

I created a snap package “a-pack” with the following slot:

slots:
  lib0-1804:
    interface: content
    content: lib0-1804
    source:
      read:
        - $SNAP/lib

Now, I created another snap package, “b-pack” with the following plug:

apps:
 b-pack:
   command: bin/b-pack-run
   plugs:
     - lib0-1804
   environment:
       LD_LIBRARY-PATH: $SNAP/extra-libs

plugs:
  lib0-1804:
    interface: content
    content: lib0-1804
    default-provider: a-pack
    target: $SNAP/extra-libs

a-pack compiles successfully and installs too (with the flags --devmode --dangerous. But when I try to compile b-pack using snapcraft, it returns the following error:

Could not install snap defined in plug 'a-pack'. The missing library report may have false positives listed if those libraries are provided by the content snap.

If I remove the plug from b-pack and all the dependent files, then everything compiles successfully. It can’t be an issue in the b-pack-run as I tested it separately and it compiles and runs fine.

Can someone guide me, what could possibly be going wrong?

So I released my a-pack snap to the Snap Store and my b-pack snap was able to find it at the time of installation. However, still, there’s no file present at the target location.
I have tried running
sudo snap run --shell b-pack.b-pack
But still I’m not able to see anything at $SNAP/extra-libs.

@svet @pedronis @cjp256 @sergiusens @jamesh @zyga-snapd
Probably you guys can help me with this.

The message from Snapcraft you quote in the initial post reads as a warning rather than an error. If it was resulted in a build failure, perhaps that warrants a bug report?

The “missing library report” it references is an attempt to check whether your snap is complete. If you use one snap to share libraries via the content interface that are used by a second snap, then Snapcraft needs to be able to find that first snap to check this.

As far as testing things out with snap install --dangerous after you’ve built the snaps, check to make sure the plug is actually connected (i.e. try running snap connections b-pack). The default policy will only autoconnect content interface plugs if the two snaps are published by the same developer. A snap installed locally with --dangerous is not linked to any developer so wouldn’t auto-connect.

If you still see problems with auto-connection after you’ve published to the store, please report them.

Thanks for your comment @jamesh !
Actually I was able to resolve the issue with the first snap by releasing it to the stable channel in Snap Store. So the missing library report is gone now. So first snap now installs when I try to compile the second one.

I ran snap connections b-pack, and I couldn’t see it connected to any slot. I had to create a connection manually using
snap connect b-pack:lib0-1804 a-pack:lib0-1804
And I was able to see my target folder created at $SNAP/extra-libs when I ran snap run --shell b-pack.b-pack
However, my use case doesn’t allow me to make a manual connection, and I am not able to figure out why it’s not able to make a connection itself.

If you release both a-pack and b-pack to the store as the same publisher, and then install those packages from the store, the interface should auto-connect.

It’s not enough to have registered the name in the store: snapd needs to know the snaps represent ones published on the store.

Actually @jamesh I was trying to use a library from the first snap package in my second snap package which is needed at the time of building the snap. For connecting both of these snap packages, I was using an interface.
Please correct me if I’m wrong, but, If I’m not able to build the snap package, I won’t be able to release it either. So what can be a better alternative? I can specify the original path of the library provided by the first snap in my second snap directly, but that would mean that I don’t have to use interfaces anymore.
Is that a better solution?

You need to tell the snap that is being built where the missing libraries would be at build time, most of the logic for content snaps is for hooking up N snaps at runtime.

You can do this by making use of the build-environment property for a part and setting whatever is required (LDFLAGS, LD_LIBRARY_PATH, …) to find said library.

Thanks for the comment @sergiusens
That’s what I’m exactly doing. I’ve set the LD_LIBRARY_PATH and LD_FLAGS but I’ve set them to find the library at $SNAP/extra-libs folder which should supposedly be generated due to the connection of slots and plugs which isn’t getting generated automatically as my second snap package isn’t on the snap store yet, so it can’t verify the publisher.
Another alternative is to set the LD_LIBRARY_PATH as /snap/a-pack/lib but that defeats the purpose of interface as I’m not actually using the interface anywhere anymore. Also, it would fail on systems where the default location of snap installation is changed.

For any future visitor:
I was able to clear out confusion in the above discussion which I feel every beginner will come across. You can check this github repository of mine where I’ve cleared out how things work with content provider regarding providing required libraries using slots and plugs.