I currently have a snap that during build time leaves metadata about its build environment in various places. I need to either clear this data up to be consistent, or make use of snapcraft layouts to just symlink/bind the locations so that they’re accessible at runtime.
Specifically, the snap is a compiler framework that JIT’s C++ code. It is leaving references to the $SNAPCRAFT_PART_BUILD and $SNAPCRAFT_PART_INSTALL folders around various locations, E.G, $SNAPCRAFT_PART_BUILD/include.
These include folders do need to exist in $SNAP at runtime, and they do, but because the metadata is still pointing to /root/ where the snap is built, it is failing due to permission errors and snapcraft layouts cannot help because new top level directories cannot be made.
I am under the impression that Launchpad has some fluidity with the location of the $SNAPCRAFT_PROJECT_DIR variable, if I was able to change this to be say, /var/snap-build ; I’d be able to use layouts to patch around the problem in a way that might be a lot easier than trying to correct it in the program itself.
And so I’m wondering, is there any way to tell snapcraft (with LXD backend, if it changes the answer) to use an alternate $SNAPCRAFT_PROJECT_DIR?
Off the top of my head, there’s no easy with with --use-lxd. But if you spin up an LXD container (matching the base, e.g. core20 => ubuntu:20.04) and install snapcraft in it, you should be able to use --destructive-mode wherever you like.
Am I correct in thinking then that $SNAPCRAFT_PROJECT_DIR just happens to be wherever the current working directory, and that the rest of the variables such as $SNAPCRAFT_PART_SRC are constructed relative?
Preferably I’d like to avoid relying on making an LXD container manually because it’d complicate running this on CI and cuts off options such as Launchpads remote build as options.
In my specific instance, I might have found a way of avoiding the issue since the original problem might be easier to handle than I originally thought and only require binary patching one file in the end, but if not, I’ll give your suggestion a go and see where it leads, thanks!
So in the end, the binary patching would be a lot more effort than I’d thought and so hacking around with the project directory is unfortunately the only valid solution, however the end result is absolutely fine for the end users so I guess that’s just how it is
I was just wondering if there was any change on snapcraft layouts being unable to create new directories in / itself, if this restriction didn’t exist then it’d make this a lot easier on me. Is it something that is likely to fixed soon?
I have no information, but I doubt this would happen anytime soon.
Another possibility would be to just use override-build: to build/install to any directory you want, copying them into $SNAPCRAFT_PART_INSTALL when you’re done? Not exactly ideal, but it should work.
No, unfortunately not. The ability to create new directories in / depends either on:
the base snap maintainer adding a specific path to the snap (even as an empty directory)
a complete rewrite in snapd of the mount logic, which would be very time consuming and is thus unlikely to be scheduled anytime soon
You may get more traction trying to convince upstream base snap maintainers to add these new directories, it probably depends on the directory and it’s use case.
Fortunately since this post, I’ve managed to work around the main issue in the build system of the snap that was causing this problem, there’s a minor chance I might have to come back to these workarounds in the future, but as far as what’s reasonable/being tested I think I’m luckily in the clear.
Overriding the build or using a custom plugin would probably have worked and I’m unsure why I didn’t think of it at the time. I think the technical answer there is probably burnout about 40 hours of effort got put into this problem by the end, so I’m thankful I didn’t have to try rewrite the CMake plugin too.
Thanks for all the advice
Edit:
Thanks for the explaination on the layouts too Ian, I’ll keep it in mind should the particular problem happen to manifest itself again, but if it does I’ll give using the override-build / plugin route a go before passing the problem onto someone else
No, it wasn’t possible to control $SNAPCRAFT_PROJECT_DIR with snapcraft --use-lxd, you’d have to enter a LXD container and run snapcraft manually (or perhaps write a wrapper for it). Alternatively you could use --destructive-mode, but this comes with huge caveats in that it generally wrecks the host system and is meant for short lived containers/vm’s.
I am curious at to your use case for needing it however, there might be better approaches to suggest if we knew what problems this was causing for you.
