Add libpolkit-gobject-1-0

[nteodosio]

Otherwise libpolkit-gobject-1.so is a dangling link to libpolkit-gobject-1.so.0.0.0.

Expands #227.

Rationale

If the package (libpolkit-gobject-1-0) is not present in the stage-packages it will not be included in the snap even if it is a dependency of a stage-package (libpolkit-gobject-1-dev). Also the build log of the gnome-sdk makes me wonder if it is being pulled at all, as I see no reference to the *-0, only to the *-dev in it.

Bug

Gnome software snap attempts to link this library statically instead of dynamically because the .so is a dangling link while the .a is the real thing.

[nteodosio]

Gnome software snap attempts to link this library statically instead of dynamically because the .so is a dangling link while the .a is the real thing.

Nah, on second thought that is balderdash. It does leave me wondering why the -dev packages include a dangling link though.

This is just the SDK right, for the runtime it will be in the non-SDK snap.

[nteodosio]

In my previous comment I had the erroneous assumption that at link time the library itself would not need to be there for a dynamic link, but I was wrong per https://stackoverflow.com/questions/9688200/difference-between-shared-objects-so-static-libraries-a-and-dlls-so:

at link time the linker looks inside the library itself to make sure the functions it needs are actually there

I did not catch that at #225 (comment) likely because at the time I provide the actual shared object meson has already configured the build.

So I re-run that test case but putting the libpolkit-gobject shared object before starting the build, rather at the end of the pull phase:

1. snapcraft pull --verbosity=trace --shell-after --use-lxd
2. Substitute libpolkit-gobject*.so* in the /snap/gnome-42-2204-sdk
3. Continue the build with snapcraft --verbosity-trace

And it built fine.

So I'm reopening this merge request.

[seb128]

Thanks, the fix makes sense to me. I'm tagging Ken and Jesus also though because I lack the context of why the -dev was added and if there was any reason at the time for letting the library out (it's also unclear why to me why it's not pulled in as a depends of the dev binary)

[kenvandine]

This looks good to me. It wasn't intentionally left out, I would have expected it to be staged as a dependency of the dev package.

[jssotomdz]

As Ken pointed out, the library is supposed to pull the library as a dependency. For some reason I still don't understand, the .so is deleted at some point. While it worked for me locally (I saw the link working) when I sent it to snapcraft the library doesn't exist (broken link). Snapcraft team told me it was because the core22 base snap is cached in my system. But besides that I don't have any further insights.

[nteodosio]

Is there any way to confirming the fix apart from releasing to stable and rebuilding affected software? Build-snaps have the snap/channel format but extensions do not.