Given the superblock.go is copied from diskfs, I wonder if I need to add something like this:

diff --git a/pkg/squashfs/superblock.go b/pkg/squashfs/superblock.go
index a90ab5b..1934e23 100644
--- a/pkg/squashfs/superblock.go
+++ b/pkg/squashfs/superblock.go
@@ -1,3 +1,10 @@
+/* This file was initially copied from go-diskfs [1].  The copied portion is
+   Copyright (c) 2017 Avi Deitcher and licensed under the terms of the MIT
+   license [2].
+    [1] https://github.com/diskfs/go-diskfs/filesystem/squashfs/superblock.go
+    [2] https://opensource.org/licenses/MI
+*/
+
 package squashfs
 
 import (

My only thought is that it would be nice to import superblock.go instead of copying it, but I suppose you tried that and it introduces some other C deps that you have to build?

The next trick to drop dependencies would be to just "shell out" to cryptsetup and dmsetup.
Normally I would argue heavily against shelling out. But I think it is different here for a couple reasons:

• 'dmsetup' and 'cryptsetup' seem to be reasonable dependencies to me . They are very mature cli interfaces that are very standard on linux.
• dmsetup and cryptsetup cover the vast majority of the dynamic dependencies that stacker needs to use.

when atomfs builds, it gets a dependency (from ldd) like the following. I marked the ones that come from cryptsetup with a '-'.

 /lib64/ld-linux-x86-64.so.2 (0x00007f8a04774000)
-libargon2.so.1 => /lib/x86_64-linux-gnu/libargon2.so.1
-libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1
-libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3
-libcryptsetup.so.12 => /lib/x86_64-linux-gnu/libcryptsetup.so.12
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
-libdevmapper.so.1.02.1 => /lib/x86_64-linux-gnu/libdevmapper.so.1.02.1
-libjson-c.so.5 => /lib/x86_64-linux-gnu/libjson-c.so.5
 liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1
 liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 
-libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 
-libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 
-libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 
-libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 
-libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 
 libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 
 libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 
 linux-vdso.so.1 

So basically if we shelled out, i think we could maybe get atomfs's deps down to only those compression libraries.

(note, stacker probably has others, i was just looking at atomfs now, and it
only imports stackerbuild.io/stacker/pkg/atomfs and
stackerbuild.io/stacker/pkg/mount, but a lot of functionality comes from just that)

My only thought is that it would be nice to import superblock.go instead of copying it, but I suppose you tried that and it introduces some other C deps that you have to build?

All diskfs exposes is a Filesystem interface. You do a Read and get one back, but then you don't have any way to get 'size' or anything even though they're in the struct.

I could propose an upstream change to expose them in a consistent manner for each of the Filesystem interface implementations; this is just lazy.

You could downcast to the right one if the individual implentations are public.
…

squashfs.Filesystem is what you get back from the Read. It has a '[superblock]' of type *superblock member that is not exposed (lower case). The superblock type has a non-exposed uint64 size.

Maybe i could manage to get it through an import, but not in any way that was clean or imo preferable to this one file copy.

oh for pete's sake. test taht failed is tests/caching.bats "can read previous version's cache".
That test does a clone of stacker and attempts to build it. I can't build the previous version of stacker because I don't have one of it's dependencies (libsquashfs1 -- thats what i'm tryint to fix).

Yeah, you'd have to do reflection, and then you're at risk of some non-public API change. Another option would be to fork + go replace, but copy seems fine too.

I think

The next trick to drop dependencies would be to just "shell out" to cryptsetup and dmsetup. Normally I would argue heavily against shelling out. But I think it is different here for a couple reasons:
...

I guess there are the following cases

1. kernel 'mount' of a squashfs+dmverity image
2. creation of verity data and root hash

It seems that mount is pretty straightforward with dmsetup or cryptsetup. creation might be a little more difficult.
if we separated use and creation into separate directories, then a consumer (such as 'machine' or 'atomfs') that only needed mount would not end up with the library dep.