Hi all. I’m trying to package btrbk, which is a Perl script for creating and managing BTRFS snapshots and backups. Since it may create snapshots anywhere on disk, it needs classic confinement in order to access host’s fs.
Snap is working fine so far (already creating and managing my snapshots/backups), but I’ve run into some issues that I’d like to share and have some words on.
Classic Snaps don’t mount a base as fs root, using host’s fs instead (any mistakes, please correct me). btrbk is a Perl script, and uses a shebang to instruct kernel on how to load it - #!/usr/bin/perl. Thing is: in a classic snap, having host fs as root, /usr/bin/perl will point to host’s Perl, which is not what I want since Snaps are supposed to be self contained. I thought of changing shebang to #!/snap/........./perl (and it worked), but then I came to know that some distributions don’t adopt /snap link, so this solution isn’t portable. I ended up creating a simple script, using #!/usr/bin/sh (and so, host’s default shell) that can use Snaps environment variables to correctly find Snapped Perl. Question is: is there a better way to deal with this situation?
Snap uses a base (core20), but since this base isn’t not mounted as root fs and isn’t ELF patched to look for libraries at the right place, I found it kind of useless. I could have used some libraries from it, to reduce Snap size a little, but that would mean having to explicitly declare core20’s library directories in LD_LIBRARY_PATH, or something like this. Am I making any mistake on this line of thought? Would it be a problem to build this Snap on a bare base?
I’d imagine usr/bin/env is reliable on all platorms - you can set the PATH to incorporate the location of perl. i.e. #!/usr/bin/env perl
Snapcraft will account for the paths when it patches the binaries in your classic snap. But as you indicated, the executables found in the base aren’t patched and I’d expect something like LD_LIBRARY_PATH is probably required, or to be avoided altogether.
I would expect a bare base would work fine if you stage libc.
As for question 1, you nailed it by using env (no need for wrapper anymore). My point persists, nonetheless: we need something from outside the Snap package (even something as ubiquitous as env) to start the script. Was wondering if there was another solution, but it seems this is the way .
I decided on keeping core20. Looking at a pldd of a running process, I see there are some core20 libraries in use. Better keep it, then.
.