Add Mosaic Mod Manager

[TheMrGeeBee]

Mosaic Mod Manager — a mod manager for Linux (Baldur's Gate 3, Bethesda titles, RE Engine games, and many more), with Nexus Mods integration, Collections support, FOMOD/BAIN installers, and LOOT sorting.

Repo: https://github.com/TheMrGeeBee/Mosaic-Mod-Manager
Releases (AppImage, GPG-signed, .zsync delta updates): https://github.com/TheMrGeeBee/Mosaic-Mod-Manager/releases

[TheMrGeeBee]

Thanks for the automated review — wanted to leave context on why it failed, in case a maintainer looks at this.

This AppImage is built with quick-sharun / pkgforge-dev/appimagetool, which uses DwarFS (not squashfs) as the embedded filesystem, embedding the uruntime AppImage runtime. That's a deliberate choice for this build — DwarFS's block-level deduplication compresses the many similar .so files an AppImage like this bundles noticeably better than squashfs does.

The AppImage's own bundled runtime handles DwarFS natively and works correctly for end users (confirmed working directly and via Gear Lever and topgrade), but this repo's test harness deliberately mounts submissions with the classic reference runtime-fuse2-x86_64 runtime rather than the AppImage's own bundled one, and that runtime only understands squashfs — hence This doesn't look like a squashfs image. It's a real format difference, not a broken build.

Happy to answer any questions. Leaving this PR open in case a squashfs-based build is a hard requirement for listing, or in case DwarFS-based AppImages are already handled some other way here — no action needed on my end otherwise.

[github-actions]

❌ Test failure

• The downloaded file is not a valid AppImage.
• The AppImage is missing a required file (see below). See https://docs.appimage.org/reference/appdir.html for what an AppImage must contain.

First error in the log:

FATAL: AppRun is missing in /run/snapd/ns

Commit 60858de. Full log

[probonopd]

Thanks @TheMrGeeBee. Indeed we can only test squashfs based AppImages at this time and I am not convinced yet that DwarFS really delilvers the magical improvements it promises. Did you compare your app with DwarFS vs. squashfs?

I have updated the README to make the restriction explicit. Thanks for bringing this up.

[TheMrGeeBee]

Thank you @probonopd for you reply.

The huge win for me is the file size. Main benefits are content-defined chunking + cross-file deduplication For Mosaic that is a self-contained app, where most of the bulk is from my own python files, Qt libs and other unique assets that gain can be substantial. Think: many versions of Perl/Python packages, or Docker image layers with overlapping files.

But your skepticism on the DwarFS has substance, I agree on that. DwarFS is using FUSE instead of the Kernel level squashfs. But on the other hand where loop-mount isn't available, for instance in a container environment or where other restricted permissions apply, squashfs would also fall back on FUSE mount.

DwarFS will be more CPU-expensive at the first run due to it's harder LZMA dictonary, but for this kind of app, that is launched occasionally rather than read like a giant static corpus repeatedly, this rarely matters in practice.

Why is the size important for me? I'm uploading each release to Nexus Mods, and a new user would have to download a much larger file. Once downloaded it auto update it self on newer releases, but it's also a matter of uploading it to Nexus Mods, and their antivirus scan would be much longer.

The only solution for me would be to build two versions of the AppImage, but in that case I would have to force a naming schema, since it will fetch the first available AppImage by name.

But I respect your decisions, and it is still available once downloaded without it being on the AppImage repo.

[probonopd]

Thanks for your detailed response. I am still pondering whether we should accept DwarFS based AppImages; in fact I have a PR ready that would allow it. But it adds complexity, especially to all the various desktop environments that integrate AppImages properly.

So your input is valuable:
How many MB do you save by using DwarFS over squashfs, do you know?

[TheMrGeeBee]

Thank you @probonopd for your response.

Good question, so I actually went and checked instead of guessing. Took my latest release (v1.5.1), pulled the files out of the DwarFS image, then repacked the exact same files into squashfs using the same mksquashfs settings appimagetool itself uses by default (zstd, no extra compression level, straight from your source so it's a fair comparison).

DwarFS comes out at 80.7 MB, squashfs at 96.3 MB. So about 15.6 MB more, roughly 19% bigger.

Honestly not a huge difference for my app - it's mostly just Python + Qt + site-packages, not the kind of repetitive stuff where DwarFS really shines. So I get why you're not convinced it's worth the extra complexity on your end, makes sense to me.

Reagrds,
Gordon

[probonopd]

+20% is not nothing, but maybe we could optimize the squashfs+zstd settings to get closer to that. I never had the time to test this systematically so far.

[TheMrGeeBee]

+20% is not nothing, but maybe we could optimize the squashfs+zstd settings to get closer to that. I never had the time to test this systematically so far.

Yes, I'm open for suggestions. My goal is to make gaming, and especially modding gtames on Linux more convenient and available. I'm not locked into DwarFS, so if you could improve the squashfs+zstd I would consider switching. It would benefit the whole Linux eco system.

Regards,
Gordon

[TheMrGeeBee]

Hello again @probonopd

Dug into this a bit more actually. The DwarFS side isn't running some default I could just tune - your build calls out to a separate tool (pkgforge-dev's Rust appimagetool) that already hardcodes zstd:level=22 -S26 -B6, so it's already at max compression level, 64 MiB blocks, and scanning back through 6 blocks (~384 MB) for duplicate content.

So the real gap isn't a missed setting on my end, it's structural: mksquashfs hard-caps block size at 1 MiB (tried passing 2M just to check, it just refuses), so it's working with a 64x smaller compression window than DwarFS, with no equivalent of that cross-block lookback at all. That's kind of the whole point of DwarFS's design, so squashfs can't really close that particular gap no matter how the flags are set.

Best I could get out of squashfs: bumping to -Xcompression-level 19 gets it from 96.3 MB to 89.1 MB, and switching the compressor to xz (still built into squashfs-tools) gets it down to 84.0 MB, only 3.2 MB off DwarFS's 80.7 MB - though xz decompresses slower, which matters since an AppImage gets read from repeatedly at runtime, not just downloaded once.

Regards,
Gordon