Publish to major package managers

[theRookieCoder]

We would ideally want to publish to the most common package managers so that updating to the latest version is easy and convenient. These are the ones I have in mind;

• GitHub Releases
• Crates
• AUR
• Scoop
• Nix Packages
• Pacstall
• Homebrew
• Chocolatey
• Debian or APT

Preferably, these packages should use the existing Releases builds rather than compiling separately.
Their packages should also be updated automatically in the release Actions workflow.

[NatoBoram]

There's a good alternative to Chocolatey on Windows: https://scoop.sh

It actually manages packages instead of just running the installer, like choco and winget.

[JustSimplyKyle]

yeah, scoop is great too.
Although chocolatey is the most well known(scoop is just behind)

[theRookieCoder]

It seems that Scoop is meant more for developer tools? Well it seems much easier to upload to anyways so I'll do both

[JustSimplyKyle]

https://gist.github.com/KyleUltimate/3e20b14ecbf6a5512912f8dc3addc4b7
This is my implementation of ferium in scoop. It's really easy to implement.
This should not even require action changing, the auto update should be done by scoop
(currently there is no hash checking because I'm lazy to check hash for windows)

[JustSimplyKyle]

I will add it later, it should also automatically update sha256sums too.

[JustSimplyKyle]

Ok now it also auto updates the hash too!

[JustSimplyKyle]

Also, do you consider ferium fitting this?
https://github.com/ScoopInstaller/Scoop/wiki/Criteria-for-including-apps-in-the-main-bucket
I think it does. Therefore
ScoopInstaller/Main#3558

[theRookieCoder]

Also, do you consider ferium fitting this?

I wasn't actually sure, I mean it isn't 'reasonably well-known' or a 'developer tool' right?

[theRookieCoder]

Oh and looking at the autoupdate, would the releases now need .sha256 files? Or is that some sort of shortcut?

[JustSimplyKyle]

I believe it's a shortcut!
Although I'm not sure bout that

[JustSimplyKyle]

Wait hmm no.
It's an direct file.
We still need to upload the sha256sum to github release too

[JustSimplyKyle]

#50
Done, haven't actually tested that tho.
It's a very simple one, it should just work

[JustSimplyKyle]

Calinou/scoop-games#616
Up!(This is the official game repository)
Installation step.

1. scoop bucket add games
2. scoop install ferium
   
   And it also auto upgrades! My pull request is 3.27.0, but it auto upgrades to 3.28.0!

[theRookieCoder]

This is great, thank you so much! Also where did you get the screenshot from, I can't find a Scoop index website with Ferium in it

[JustSimplyKyle]

https://scoop.sh/#/apps?q=ferium

[ImperatorStorm]

You can create packages for multiple distros(Debian+Debian-based, Arch, basically all of the RPM distros...) and automatically make repositories for them via https://build.opensuse.org.

You can use https://build.opensuse.org/package/show/home:ImperatorStorm/minizip-git as an example if needed, and via a beta automatically trigger an OBS rebuild on commit.

[JustSimplyKyle]

Another AUR release!
https://aur.archlinux.org/packages/ferium-git
This is ferium-git, which automatically compiles from source!
The package version will always be "outdated", but the actual package won't...
In short words, it auto upgrades and doesn't require any changes to ferium itself

[theRookieCoder]

How does it know when it should recompile, does it infer that from the tags/commits?

[JustSimplyKyle]

Well the thing with git packages is that the upgrading is done on the user side.
When the user decides to build(or upgrades) the package, it automatically pulls from the latest commit.
But the upstream package version will never get upgraded. eg.

The left version continuous.r1621.g41a49c488-1 is what you see on AUR
But the right Installed: continuous.r1940.g6613ff329-1 is the version you actually get

[theRookieCoder]

Ah I see, and now from-source builds don't need the CurseForge API key environment variable anymore so perfect timing!

[JustSimplyKyle]

Actually, you don't need to state that it require the rust toolchain since it has cargo in makedepends(which automatically configures the rust toolchain for you, and you can choose to uninstall makedepends after your installation but that's normally not recommended although it would function)

[theRookieCoder]

I just wanted to warn the user that it will install additional stuff that might be quite large because the Rust toolchain is over 5gb I think

[JustSimplyKyle]

hmm, I can't get just build-linux to work, but I could get just build-linux-nogui to build? it seems like build-linux will also build for windows but I don't have the windows toolchain so it doesn't work.
Currently I'm tweeking the -git package to automatically build the nogui version if you don't have gtk3 installed, and build the normal one if you do have one installed.
But I'm running into this problem...
Is this the same problem that this issue has?
#69

[ImperatorStorm]

Looks like it, cargo doesn't auto-install toolchains that aren't for the host OS, you'd need to install them manually.
Fixed in #71 once it gets merged.

[JustSimplyKyle]

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=ferium-git
Yep after the latest commit, this now works!

[ImperatorStorm]

why keep it as a single package, rather than split it like the binary packages?

[JustSimplyKyle]

Because that's what people normally do for source packages, enable features if your computer has that functionality.
But for binary packages, it's not the normal thing to do
Also another reason, I don't know how to download only a single source 🤣

[ImperatorStorm]

Nah, people split packages into cli and gui versions commonly, see citra-git and dolphin-emu-git.
Also, changing build depending on whether a certain package is available breaks reproducible builds.

Rewrote the ferium-git PKGBUILD:
https://gist.github.com/ImperatorStorm/bbe40ed329f5706740b54c4e9bec0933

Unrelated, but

gtk optdepends should be gtk3, as gtk refers to a gtk1 aur package (https://aur.archlinux.org/packages/gtk)

[theRookieCoder]

Homebrew/homebrew-core#106034

[theRookieCoder]

@Southpaw1496 what do you think?

[theRookieCoder]

Yet another package manager, ferium is now available on Homebrew!

[JustSimplyKyle]

https://aur.archlinux.org/pkgbase/ferium-git/
Does anyone have any idea why it can't build in clean chroot?

[theRookieCoder]

I think the issue is that the zip crate depends on bzip2 and Zstandard. (zstd is what's missing in your build failure) Actually those are used for compression, but ferium only needs to decompress modpacks (at least till #98 is implemented). So I should be able to just disabled those features, then neither bzip2 nor zstd would be required!

[theRookieCoder]

Damn like 20 dependencies just went poof. Maybe I should go through all the crates and disable unnecessary features...

[theRookieCoder]

Oh yeah @JustSimplyKyle both bzip2 and zstd were removed so those are no longer required

[theRookieCoder]

@JustSimplyKyle Do the binaries still have a dependency on bzip2? If not, the AUR packages seem to still specify it as a dependency, could you remove that too?

[JustSimplyKyle]

No problem! This kinda flew over iy head, will do!

[theRookieCoder]

@imsofi is there a way to automatically create a PR that updates the nixpkgs ferium package? For example for homebrew I was able to find https://github.com/mislav/bump-homebrew-formula-action but I just can't find anything like that for nixpkgs.

[soupglasses]

@r-ryantm is a bot in nixpkgs that auto-updates packages. For example: NixOS/nixpkgs#210427 (comment)

They use the https://github.com/ryantm/nixpkgs-update project to update, but its more designed to update the entirety of nixpkgs.

https://github.com/Mic92/nix-update could be closer to what you are looking for. Should be runnable with something like nix-update ferium

[KokaKiwi]

@theRookieCoder

I emailed the maintainer, and requested deletion on AUR because it's unofficial and can be confused with the official packages

Hello, I just re-instated my (updated) AUR stable source-based package for ferium at: https://aur.archlinux.org/packages/ferium

It would be nice to simply flag as out-of-date the package (there's a dedicated link for that on AUR package pages) instead of requesting their deletion, especially when i already replied why i created this AUR package the last time you requested its deletion (and was at the time rejected because of the lack of other stable source-based AUR package)

[theRookieCoder]

Uhh I did not get any message/email from you about your reasons for this package existing, my Discord is theRookieCoder#1287 if you'd like to chat. There are source-based packages available (those suffixed with -git) btw so your package still qualifies as a duplicate

[theRookieCoder]

was at the time rejected because of the lack of other stable source-based AUR package

The packages back then were exactly the same as they are right now, I just did not properly link to them in my request.

[KokaKiwi]

Uhh I did not get any message/email from you about your reasons for this package existing, my Discord is theRookieCoder#1287 if you'd like to chat

I replied to the deletion request email i had, but not the other one you sent (i think it went lost among the spam i receive, sorry ><), so maybe that's why uh :(

In my reply i actually proposed to add you as co-maintainer of the package so you would be able to update the package yourself when needed

There are source-based packages available (those suffixed with -git) btw so your package still qualifies as a duplicate

There's a huge difference between "latest commit source-based" packages and "stable source-based" packages actually.
The AUR has basically this naming-scheme for packages:

• <package> : Package which build from source against the latest stable release
• <package>-git : Package which build from source against the latest commit on the repository, often considered as "unstable packages", since it's akin to a "dev build"
• <package>-bin : Package which build from binary release against the latest stable release, generally used on platform not able to compile stuff (for instance i use them on my rPi ^^)

[theRookieCoder]

I replied to the deletion request email i had

hmm I didn't receive anything, I checked my spam/junk inboxes but I can't find anything. Anyways,

There's a huge difference between "latest commit source-based" packages and "stable source-based" packages actually.

Thanks for the clarity! (and apologies for the confusion 😬)
Does the 'stable' source-based use the latest git tag?

Well there is some missing information in your package:

• There is no GUI version of the package
• GCC is not required since ferium uses musl to build
• Not sure if this is strictly necessary but you should probably add git as a dependency too
• The repository url hasn't had the organisation name updated
• You should fill out the conflicts and provides fields (particularly because there should ideally be 6 packages for ferium, which would all conflict)

One last doubt, does this package need manual updating of the git tag? That can be added to the workflow so it updates automatically whenever I push and update.
If you need any help, I'm pretty sure @JustSimplyKyle can give you hand 😁

[KokaKiwi]

Thanks for the clarity! (and apologies for the confusion 😬)

It's okay, i understand how confusing AUR can be for people ^^

Does the 'stable' source-based use the latest git tag?

Yup, i actually enabled notifications for this repository when releases are pushed so i could update my package 😄 (but seems i actually forgot to do this since some times uh ><)

• There is no GUI version of the package

No worry, in the time you wrote this i actually pushed the GUI version of my package: https://aur.archlinux.org/packages/ferium-gui :p

• GCC is not required since ferium uses musl to build

Actually for source-based packages, you need gcc-libs as dependency since on arch it builds by default against gcc, not musl (unless i specify the --target manually which can be tricky when using the rust package from official repositories)

• Not sure if this is strictly necessary but you should probably add git as a dependency too

The source the package use is actually the archive version of the repository, which allows using checksums for source-integrity checking, so git is not necessary :)

• The repository url hasn't had the organisation name updated

Whoops i didn't notice so i'll update this ASAP ^^

You should fill out the conflicts and provides fields (particularly because there should ideally be 6 packages for ferium, which would all conflict)

Actually that shouldn't be needed since the other packages already have the provides field, which automatically setup the conflicts rules and stuff
Also adding provides=('ferium') on a package already named ferium is basically a noop so it's not needed either :)

One last doubt, does this package need manual updating of the git tag? That can be added to the workflow so it updates automatically whenever I push and update.
If you need any help, I'm pretty sure @/JustSimplyKyle can give you hand 😁

As i said, i'm actually notified on every new releases you push here so i can update my AUR packages when needed (i do that for every packages i maintain on the AUR ^^)
It seems i didn't took much time to update some packages (mostly because of life stuff ><), so i forgot to update the package :x
But on those cases don't hesitate to push the "Flag as out-of-date" link on the AUR package page so it'd yell at me to update the package xD

idk about how we could hook the workflow to update the package but i'd be interested for help on how to do that yeah :D

[JustSimplyKyle]

Actually that shouldn't be needed since the other packages already have the provides field, which automatically setup the conflicts rules and stuff

Oh really, that's cool! So I can just remove every conflict that I have?

Actually for source-based packages, you need gcc-libs as dependency since on arch it builds by default against gcc, not musl (unless i specify the --target manually which can be tricky when using the rust package from official repository

I've tried to build my packages in clean chroot, and it does build!(using musl)

[JustSimplyKyle]

To use the workflow, first add Ilesh to co-maintainer
Then it should be as simple as adding the following to the release.yml

      - name: Update gui AUR package
        uses: ATiltedTree/create-aur-release@v1
        with:
          package_name: ferium-gui
          commit_username: "Ilesh Thiada"
          commit_email: ileshkt@gmail.com
          ssh_private_key: ${{ secrets.AUR_SSH_PRIVATE_KEY }}

[Nukecraft5419]

Could we also have a version for npm, and also a discord to have better support and contact also

[theRookieCoder]

Hmm not sure why ferium would need an npm package? It has absolutely nothing to do JavaScript.

I never really expected this project (or any of my projects) to go this far, so I haven't considered a Discord server yet. You can use the GDLauncher server for now in the gdlauncher support channel with the Ferium tag.

[Nukecraft5419]

Basically I'm creating a hybrid Launcher between the official Minecraft Launcher and MultiMC based on Electron and uses javascript/typescript I'm still deciding on this thing because there are 2 versions of electron then I'll use React and Chakra UI and I also have a client similar to Lunar and others I'm all about fabric with all mods not made by me and I wanted to make that only in my launcher there was the download via the ferium script

[RokeJulianLockhart]

@theRookieCoder, you'll get a lot more exposure if you manage to publish to

0. snap and
1. flatpak (at least for the GUI version)

since they support every Linux distribution except Android. Additionally, flatpak is the sole method of persistent installation of Fedora (Silverblue and Kinoite).

[theRookieCoder]

I'm not all that familiar with Linux but aren't these for GUI desktop applications? Ferium is still CLI only and there aren't any plans for a GUI port yet.

But yeah your concern is valid, I find it frustrating too that there isn't an easy way to reach all (if not most) Linux users easily. I'm thinking of using Fedora and it pains me to not see my own software on it.

[ImperatorStorm]

Snap works for both cli and gui, but is jank in other ways.
Flatpak can work for CLI, but iirc it'll take additional user input

[soupglasses]

But yeah your concern is valid, I find it frustrating too that there isn't an easy way to reach all (if not most) Linux users easily. I'm thinking of using Fedora and it pains me to not see my own software on it.

One universal packaging method available to all distros right now is nix. Which on Fedora you can install trough a dnf package from here: https://github.com/nix-community/nix-installers

There is also the official method, which works well on other distros if not supported by nix-installers: https://nixos.org/download.html

Then running nix profile install nixpkgs#ferium should put it into your PATH 👍

[soupglasses]

A side note is that you can also run any software from nix with nix run nixpkgs#package-here without installing it to your system. Which is how i personally end up running ferium for updating my mods 😄