Add support for statically linking e2fsprogs

[chenxiaolong]

This makes it possible to easily build the project on Windows and macOS, where e2fsprogs isn't easily installable. When building with the new static feature, mke2fs will be embedded into afsr as a hidden subcommand to avoid any external runtime dependencies.

This PR also relicenses afsr to GPLv2+ (effectively GPLv2) to resolve license conflicts that previously prevented distribution of binaries.

Issue: #2

[chenxiaolong]

This is not quite ready yet.

TODOs:

• Release new version of cargo-android with required changes for the CMake build to work
• See if we can use pkg-config for the -F static path to avoid having two ways of linking e2fsprogs
• For -F static builds, update afsr to look for the mke2fs executable that lives next to afsr
• Test Github Actions workflows

[chenxiaolong]

Ugh, NDK 27 is broken with CMake's builtin Android support (https://github.com/android/ndk/issues/2049).

[chenxiaolong]

Thanks to Debian for detailing the license per file: https://android.googlesource.com/platform/external/e2fsprogs/+/refs/heads/main/debian/copyright

I wasn't thorough enough when looking into the licenses. It turns out not all of lib/ext2fs/ is LGPLv2. There are some GPLv2 files too. That means distributing a prebuilt afsr executable right now would be a license violation.

I think there are only two ways forward:

1. Never distribute afsr binaries--only distribute the code. This would be like the ZFS + Linux kernel situation due to license conflicts.
2. Relicense afsr to GPLv2 and remove all dependencies that are Apache2-only. I need to investigate to see what exactly would need to be removed or replaced. If this is feasible, then we drop all the cmake and separate mke2fs executable stuff and just build everything into afsr.

[chenxiaolong]

❯ cargo deny check
error[rejected]: failed to satisfy license requirements
  ┌─ registry+https://github.com/rust-lang/crates.io-index#[email protected]:4:12
  │
4 │ license = "Apache-2.0"
  │            ━━━━━━━━━━
  │            │
  │            license expression retrieved via Cargo.toml `license`
  │            rejected: license is not explicitly allowed
  │
  ├ Apache-2.0 - Apache License 2.0:
  ├   - OSI approved
  ├   - FSF Free/Libre
  ├ clang-sys v1.8.1
    └── bindgen v0.69.4
        └── (build) afsr v0.1.0

error[rejected]: failed to satisfy license requirements
  ┌─ registry+https://github.com/rust-lang/crates.io-index#[email protected]:4:12
  │
4 │ license = "Apache-2.0 WITH LLVM-exception"
  │            ━━━━━━━━━━────────────────────
  │            │
  │            license expression retrieved via Cargo.toml `license`
  │            rejected: license is not explicitly allowed
  │
  ├ Apache-2.0 - Apache License 2.0:
  ├   - OSI approved
  ├   - FSF Free/Libre
  ├ winx v0.36.3
    └── cap-primitives v3.1.0
        └── cap-std v3.1.0
            └── afsr v0.1.0

advisories ok, bans ok, licenses FAILED, sources ok

clang-sys is fine. That's only used during the build and no code is linked into the final executable.

winx is also fine because Apache2 with LLVM exception is explicitly meant for GPLv2 compatibility.

[chenxiaolong]

Looks like I'll be relicensing to GPLv2 then. afsr's own code will be GPLv2+, but any compiled binary will effectively be GPLv2 due to the inclusion of e2fsprogs' GPLv2 code.

[chenxiaolong]

I'm going to move avbroot's changelog tools (avbroot/xtask/) to a separate repo so I can use it in all my projects. I'm tired of copy/pasting that in all my projects.

[pixincreate]

I'm going to move avbroot's changelog tools (avbroot/xtask/) to a separate repo so I can use it in all my projects. I'm tired of copy/pasting that in all my projects.

So this would be an additional dependency on all of your projects? Or will they be automatically cloned during build time such that executables contain them all?

[chenxiaolong]

So this would be an additional dependency on all of your projects? Or will they be automatically cloned during build time such that executables contain them all?

It won't be needed at build time nor runtime. It's purely for me managing releases.

For example, in avbroot, I previously had cargo xtask set-version -V <version> to update the project's version numbers and cargo xtask update-changelog to regenerate the links in CHANGELOG.md. These are what I'm splitting out.

[pixincreate]

Got it