snap does not create podman link in /var/lib/snapd/snap/bin

[matihost]

https://snapcraft.io/install/podman/centos does not work

sudo snap install podman --edge --devmode

it does not create podman link in /var/lib/snapd/snap/bin

After doing that manually, it does not run on CentOS
Manually fixin devmapper.so - reveals old version of podman 0.11

Is it really snap being supported?

[github-actions]

This issue had no activity for 30 days. In the absence of activity or the "do-not-close" label, the issue will be automatically closed within 7 days.

[rhatdan]

@lsm5 @jnovy What should we do with this issue?

[lsm5]

@abitrolly could you PTAL?

[lsm5]

@cevich was the snap version fixed?

[abitrolly]

@lsm5 no, no progress on fixing the version. #4135 I may take another look at it this weekend, but I really need to care about myself and do commercial stuff instead, so I better not promise anything.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[abitrolly]

The problem is probably that podman can not be built on Ubuntu 18.04 with native go. Or dependencies are missing. Either way snap build needs Ubuntu 18.04 libs and fails there.

[cevich]

Idea: What about using Fedora to do the snap build, it's got everything go-related available as native packages?

[abitrolly]

@cevich there is no Fedora base https://snapcraft.io/docs/base-snaps

[cevich]

Sorry I was not very clear. Right now the test and upload CI jobs use a container image: yakshaveinc/snapcraft:core18. I'm wondering if we make a Fedora version of that image, if that might help with the dependency problems. I'm not opposed setting up quay.io to build an image, for example from a ./contrib/fedsnap/Dockerfile. I just don't know what needs to go into that.

[abitrolly]

@cevich it won't help. If snap is based on core18, then snapcraft will spin up Ubuntu 18 and build the snap inside. For core it will be Ubuntu 16. My image is a hack only for core18 snaps to avoid spinning that new image - snapcraft sees that it is launched in Ubuntu 18, already in container, and the snap that needs to be built is to be run on the same Ubuntu 18. In that case it doesn't try to create the VM or a new container (the operation fails inside container). That allows to run snapcraft inside docker/podman containers.

The workflow tree to fix that.

1. Ubuntu 18.04 and build podman there from scratch, without snapcraft
2. Repeat the build with snapcraft
   2.1 If the build fails, turn on all debug info in snapcraft and repeat in step by step
   2.2 If that still fails, repeat what snapcraft is doing manually (needs reading Python code and most likely patching snapcraft)

---

To automate debugging build problems, there should be a way to describe packaged dependencies in cross-platform manner, or to lookup if they are packaged for another distro.

In particular, this needs checking podman dependencies from Fedora on Ubuntu. They were manually collected previously and listed in snapcraft.yml

Use distro-independent format for describing dependencies

a.1 Use repo URL of upstream source
a.1.1 Get upstream source URL from binary package info - impossible - I discovered that binary package RPMs do not carry that info while trying to sole https://discussion.fedoraproject.org/t/check-requirements-txt-against-existing-packages/2173 (wish I had better prooflink)
a.1.2 Get upstream source URL from source package
a.1.2.1 Detect source package name from binary package name
a.1.2.2 Use mdapi repology/repology-updater#906
a.1.2.x Check upstream source URL is valid to be used as id

Lookup package name using online services

Use https://release-monitoring.org and/or https://repology.org/ to lookup canonical package name for Fedora package, and then use canonical name to lookup Ubuntu package name for a dependency.

---

It just hard to get myself start doing that. I am using podman on Fedora natively after all, and while it was fun building CI automation for snapcrafting, troubleshooting go build problems with Linux packaging is not fun.

[cevich]

oh wow, gosh, that's a lot of detail, thanks for explaining. I'll need some time to read/understand that better.

Note: We're not necessarily limited to containers in this environment. I could allocate a VM to run for the snap build, whatever distro. flavor is needed. Not sure if that's helpful yet or not before I read 😄

[abitrolly]

@cevich I reworked the text to make it easier to read.

[abitrolly]

@cevich running the build on Ubuntu 18.04 and then just packing the binaries might be much much easier.

[cevich]

running the build on Ubuntu 18.04 and then just packing the binaries might be much much easier.

Yes, and also better from a maintenance perspective. Long-term, we want something both simple (for reliability) and with zero or very little additional human maintenance. So, if the packaging process could be tied (for example) into the build process we use for running tests, it won't add any new maintenance on top of what I already perform.

In fact, it's possible to cache the output-files from the testing stage for re-use in packaging. Can snapcraft produce a package, given the paths to files and the locations where they should be installed?

Please correct me: I thought snap packages were intended to be distro-agnostic by design, no?

Also, there is an option to enable nested-virtualization, would the snap building process be simpler if we used a VM with this enabled?

[rhatdan]

@cevich @lsm5 What's the scoop on this one, can we close it?

[abitrolly]

Can snapcraft produce a package, given the paths to files and the locations where they should be installed?

Yes. https://snapcraft.io/docs/dump-plugin

Please correct me: I thought snap packages were intended to be distro-agnostic by design, no?

They depend on system libraries that are no distributed. Also depend on system interfaces with host through these libraries that need to be tested. https://snapcraft.io/docs/supported-interfaces

Also, there is an option to enable nested-virtualization, would the snap building process be simpler if we used a VM with this enabled?

snapcraft uses multipass to start LXD or VM and build inside it. It can also do build inside docker and podman - detect that it is being run in a container and avoid spawning VM.

[cevich]

Okay, so the dump-plugin seems to be the way forward here. I believe I can generate the list of destination files automatically at 'make' time, where does this data need to end up for snap to do it's thing?

[cevich]

Related: #4511 (meaning: We really should be doing build/release work from automation on the $DEST_BRANCH head).

[rhatdan]

@cevich Any movement on this

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@cevich any update?

[cevich]

@abitrolly where are you at with the snap-package stuff, I haven't seem much activity. I'm okay if you feel it's time to give up with the implied option of future work, maybe from a different angle. Okay if we close this (and the related PR) for now?

[abitrolly]

@cevich snapcraft doesn't work on Fedora. It uses multipass to run builds in isolated environment, and there is a firewall problem with multipass on Fedora - canonical/multipass#1448