Packaging solutions

[intergrav]

At the time of writing, there are only two official ways for using the Modrinth App on Linux - AppImages and Debian packages. While this is fine for people on Debian-based distributions, and those who like using AppImages, some may prefer to use a package manager such as flatpak or dnf as it's easier to manage packages that way. According to this comment, the current compiled Debian packages aren't very great right now because they don't include proper dependency info and leave out some important stuff.

Along with AppImages and Debian packages, there are various packaging solutions to consider. If there's other packaging types that you think would be a good idea, suggest them in this thread. I personally think that the Flatpak should be maintained by Modrinth, and the rest could be maintained by members of the community if they wanted to do so. I think this is especially important as the Modrinth App is now in an open beta.

This issue serves as a place to discuss packaging, and I'll also treat this as a sort of "unofficial download page" for Linux users with updated information on what packages to use and where to get them.

Indicators

✅

1. a package exists and works properly
2. that package is considered ready for daily use
3. that package is available on commonly used repositories, such as a Flatpak being on Flathub for example

🔃

1. same as 1 and 2 in the above
2. however, that package is not available on commonly used repositories, but is available on a developer's personal repository. this may not be applicable for some solutions and will use the checkmark icon instead, such as COPR

Unix/Unix-like packaging

✅ Flatpak

Package is available and maintained on Flathub - com.modrinth.ModrinthApp - thank you @getchoo and other contributors!

Package that can be used on most common Linux distributions, and also good for security as Flatpaks are sandboxed unlike other types. This will be the package that most Linux users are looking for.

Notable mentions/issues

• [feat] Bundle Tauri apps as Flatpak tauri-apps/tauri#3619 (@Hyphrio)
• May be tricky to upload to Flathub, see this comment

Who's working on this?

• @getchoo is currently working on a package add upstream distribution sources for linux + flatpak package #559
• @getchoo opened a PR for Flathub Add com.modrinth.ModrinthApp flathub/flathub#4950

✅ Arch

Packages are available and maintained on the AUR - modrinth-app, modrinth-app-bin, and modrinth-app-appimage - thank you Antti!

Any ideas on this?

• @offbeat-stuff suggested making a PKGBUILD that extracts the deb package to be used as an Arch pacman package. Here's an example

Notable mentions/issues

• [feat] Arch support for tauri bundler tauri-apps/tauri#3728 (@Hyphrio)
• feat(bundler): Add Pacman package support, closes #3728 tauri-apps/tauri#4301 (@Hyphrio)

Who's working on this?

• Antti has made two AUR packages
  • modrinth-app
  • modrinth-app-bin
• Nixuge has made two AUR packages, however they could be broken as they miss many dependencies
  • modrinth-app-git
  • modrinth-cli-git

✅ Nix

Package is available and maintained on Nixpkgs - modrinth-app - thank you @getchoo and other contributors!

Nix can be used on both Linux and Darwin systems and is the package manager for NixOS.

Who's working on this?

• @getchoo has a PR in nixpkgs modrinth-app: init at 0.7.1 NixOS/nixpkgs#289149
• @getchoo is also working on a Nix flake feat: add nix flake #561

✅ Homebrew

Package is available and maintained on Homebrew Cask - modrinth.

Homebrew is a package manager for MacOS (and Linux). Idea from #560. It would allow for easy installation on MacOS.

✅ Gentoo

Package is available and maintained on Gentoo GURU - modrinth-app-bin - thank you @Norbiros and other contributors!

User-maintained package repository for Gentoo.

Fedora Copr

User-maintained package repositories for Fedora, CentOS Stream, and RHEL. Can be enabled with dnf copr enable <author>/<repo>

Notable mentions/issues

• [feat] Bundle Tauri apps as RPM tauri-apps/tauri#4402 (@Hyphrio)
• May be difficult, see this comment

Windows packaging

🔃 🍨 Scoop

Package is available and maintained on brawaru/bucket - thank you @brawaru!

Scoop is a command-line installer for Windows. It has many benefits, such as installing packages in a portable way (by default, it installs packages to ~/scoop). Package manifests are just simple JSON files - this shouldn't be too hard to set up.

✅ WinGet

Package is available on WinGet - currently looking for maintainers!

WinGet is Microsoft's own package manager.

Other information

Theseus is very complex to package and doing so for many different formats at a time would be a little chaotic. I think that the common package types like Flatpak, Arch and Nix packages should be done.

Leave your thoughts below!

For discussion, see the thread in the #development channel of the Modrinth Discord. You can also continue discussing here if you prefer that.

[Hyphrio]

For Linux these two Tauri issues are related:
tauri-apps/tauri#4402
tauri-apps/tauri#3619

[offbeat-stuff]

At least make a PKGBUILD that extracts the deb package to be used as an archlinux pacman package.

[offbeat-stuff]

Here is a PKGBUILD for archlinux that extracts a .deb package

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=linux-xanmod-linux-bin-x64v3

[getchoo]

At least make a PKGBUILD that extracts the deb package to be used as an archlinux pacman package.

this isn't a good method for the long term, especially as arch is known to make abi incompatible changes to packages frequently, or at the very least push versions of libraries usually incompatible with those found on debian/ubuntu based distros (there are also problems between those, but usually less so). here's a good example

for a temporary thing it would probable be fine? but ideally all community packages should be built against their distro's packages to ensure the final binaries actually work

[getchoo]

I personally think that the Flatpak should be maintained by Modrinth, and the rest could be maintained by members of the community if they wanted to do so.

i 100% agree with this. it's very hard and completely impractical for upstream to support the endless amounts of linux distributions out there; universal solutions should be the main focus here, along with basic files for distribution that can be used there and in downstream packages

Flatpak/Flathub

the biggest issue here is that networking may need to be enabled during building due to flatpak's build tools lacking support for pnpm lock files. this is a problem since flathub doesn't really like that and it could make it very difficult for it to be uploaded there

Nixpkgs

this is pretty much complete and fully working on any linux distro. macos support for is being worked on. the problem with pnpm and offline builds also showed up here, but since nix is a lot more flexible with it's build process, i was able to figure out a way to maintain reproducibility while still using pnpm's lock file. i will try to upstream this in nixpkgs once a stable release is made

Fedora Copr
Arch User Repository
Alpine Linux packages

like you said, these should probably be community packages. i would like to note though that some may be difficult (mainly fedora rpms) due to the issue with pnpm and offline builds as mentioned before. arch is very lose with this though so it should work fine; i can't say anything about alpine since i've never used/packaged for it personally

the only other thing i would like to note is that tauri's native package export feature really shouldn't be used here. the current debian package for example seems to strip out the other tools theseus provides such as it's cli, doesn't include dependency information (i'm assuming the direct dependencies of theseus are compiled statically...which isn't great but works ig) which can cause issues with even launching minecraft, and in general is very inflexible for the future where manual intervention for packaging may be required. i'm shocked the deb package works in it's current state, let alone if it can even actually start minecraft ootb. we should be following the standard of other linux packages (specifically packages for other launchers) by supporting the formats themselves instead of relying on a tool that in all honestly, doesn't produce good packages. most of this will fall on the community of individual distros, but for a download link on the upstream maintainer's website, poorly auto generated debs and appimages aren't really acceptable for "linux support" imo. the best solution to fix this is flatpak

edit: macos support for nix is available now. discussion about upstreaming to nixpkgs will be in NixOS/nixpkgs#247468 (thanks PC!)

[Hyphrio]

Tauri issue and PR for Arch Linux:
tauri-apps/tauri#3728
tauri-apps/tauri#4301
PR seems to be related for Pacman but seems to have stalled

[CompeyDev]

I'd be willing to draft PKGBUILDs for the AUR, just lmk.

[TheoCGaming]

If you do go for Flatpak, please, PLEASE include proper permissions. I'm tired of having to deal with broken permissions on Flatpak packages.

[MagmaBro123]

If you do go for Flatpak, please, PLEASE include proper permissions. I'm tired of having to deal with broken permissions on Flatpak packages.

Flatseal can help with fixing those, but agreed.

[intergrav]

Flatseal can help with fixing those, but agreed.

The user shouldn't have to use Flatseal to fix broken permissions provided by the package, that's just bad design

[MagmaBro123]

Flatseal can help with fixing those, but agreed.

The user shouldn't have to use Flatseal to fix broken permissions provided by the package, that's just bad design

Again, I said I agreed