Publish to major package managers
theRookieCoder opened this issue · 101 comments
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.
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.
yeah, scoop is great too.
Although chocolatey is the most well known(scoop is just behind)
It seems that Scoop is meant more for developer tools? Well it seems much easier to upload to anyways so I'll do both
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)
I will add it later, it should also automatically update sha256sums too.
Ok now it also auto updates the hash too!
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
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?
Oh and looking at the autoupdate, would the releases now need .sha256 files? Or is that some sort of shortcut?
I believe it's a shortcut!
Although I'm not sure bout that
Wait hmm no.
It's an direct file.
We still need to upload the sha256sum to github release too
#50
Done, haven't actually tested that tho.
It's a very simple one, it should just work
Calinou/scoop-games#616
Up!(This is the official game repository)
Installation step.
scoop bucket add gamesscoop install ferium
And it also auto upgrades! My pull request is 3.27.0, but it auto upgrades to 3.28.0!
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
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.
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
How does it know when it should recompile, does it infer that from the tags/commits?
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
Ah I see, and now from-source builds don't need the CurseForge API key environment variable anymore so perfect timing!
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)
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
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
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.
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=ferium-git
Yep after the latest commit, this now works!
why keep it as a single package, rather than split it like the binary packages?
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 🤣
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
gtkoptdepends should begtk3, asgtkrefers to a gtk1 aur package (https://aur.archlinux.org/packages/gtk)
oh, my apologies.
https://aur.archlinux.org/packages/ferium-git
https://aur.archlinux.org/packages/ferium-gui-git
And the ferium-gui-bin dependencies is set to gtk3!
Thanks so much for your help, I still need to learn a lot about AUR packaging!
I opened a PR for NixOS/Nixpkgs: NixOS/nixpkgs#173201
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.
I have created a working package for OpenSUSE Tumbleweed on the OBS, I recommend branching my project and integrating it into the workflow with the guide mentioned above for autobuilds. I can also see if I can enable support for other RPM based distros if there is any interest.
I opened a PR for NixOS/Nixpkgs: NixOS/nixpkgs#173201
@leo60228 I've released v3.28.8 so that patch can be removed. You should probably add the macOS Intel and arm assets too.
I have created a working package for OpenSUSE Tumbleweed on the OBS, I recommend branching my project and integrating it into the workflow with the guide mentioned above for autobuilds. I can also see if I can enable support for other RPM based distros if there is any interest.
I'm quite confused as to how to integrate this into the workflow. I'm not very familiar OpenSUSE
I'm quite confused as to how to integrate this into the workflow. I'm not very familiar OpenSUSE
See https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.scm_ci_workflow_integration.html
I can also see if I can enable support for other RPM based distros if there is any interest.
Just enable them and see which ones break.
Also, you can enable debian-based support with a project config like this. Use a subproject specifically for Debian-based distros like I did here so you don't break the builds for non-Debian-based distros.
Also, enable the services in https://build.opensuse.org/package/view_file/home:Blackcatmaxy/ferium/_service?expand=1.
Also, enable the services in https://build.opensuse.org/package/view_file/home:Blackcatmaxy/ferium/_service?expand=1.
Tried that and it seemed to break everything, had to revert that change. For the record I'm trying to follow these docs although I already figured out that it led me astray once by having auto updating cargo enabled in the services.
Tried that and it seemed to break everything, had to revert that change. For the record I'm trying to follow these docs although I already figured out that it led me astray once by having auto updating cargo enabled in the services.
Submitted a request to fix the auto-download service, should just download on version bump.
You will need to bump the version in both the _service file and the .spec file, however.
Also, this should work fine for most rpm distros.
Fedora 36 doesn't seem to package cargo-packaging, which Fedora 36 needs to build Ferium. You're probably going to need to branch it to your home:Blackcatmaxy project, build it for Fedora 36, and then trigger a rebuild for Ferium.
Now getting unresolvable: have choice for (glibc-langpack-en or glibc-all-langpacks) needed by obs-service-obs_scm-common: glibc-all-langpacks glibc-langpack-en. Figure I want to do something like "if Fedora buildrequire glibc-langpack-en"?
EDIT: Did that and got it working (although I'm not going to test it, at least not anytime soon maybe will get a VM later), think there's any point in the other architectures?
Can probs add i386 and aarch64 support, iirc i386 is supported <1.19 and aarch64 linux natives are bundled in lwjgl in 1.19+.
Don't remember the exact snapshots, so I could be incorrect.
You should probably add the macOS Intel and arm assets too.
@theRookieCoder I don't have a Mac to test so that'll be a bit annoying. I added Security.framework, which seemed to be the only issue on CI?
Hmm what do you need to check on macOS, I might be able to help you. But again I really don't understand how nixpkg and obs work
Hmm what do you need to check on macOS, I might be able to help you. But again I really don't understand how nixpkg and obs work
OBS is essentially a giant CI/CD service (think an open source GitHub actions but oriented around packaging and even bigger) for building traditional applications like .rpms, .debs, and .appimages. (EDIT, also a key part is allowing users to create package update repositories in a secure and transparent manner).
NixPkgs (probably not going to do them justice) are closer to Flatpaks in that they're a newish package format that expresses their dependencies and can actually be installed on any distro (and even on MacOS?), it's something I've been meaning to try out but haven't had time.
These are both oversimplifications and I recommend reading some of the links included although the Nix docs are a bit overwhelming.
I opened a PR for NixOS/Nixpkgs: NixOS/nixpkgs#173201
Ah you seem to have gotten to it before me, I am currently running a NUR package for ferium here: https://github.com/imsofi/nur-pkgs/tree/main/pkgs/ferium
Hmm what do you need to check on macOS, I might be able to help you. But again I really don't understand how nixpkg and obs work
Nix is just a package manager, in a similar vein to apt, dnf and homebrew. But its unique feature is that every step to build a package (called a derivation under nix) is completely versioned, similar to how git does versioned commits.
For how to help, you can take a look at installing nix (the package manager) trough https://nixos.org/download.html#nix-install-macos . There is likely other alternatives around which dont use the sh < (curl url) antipattern, but its the simplest way i know get it installed properly on macos.
For testing, you could clone my repo at https://github.com/imsofi/nur-pkgs/ . It is much lighter than attempting to pull in the entirety of nixpkgs, as its just my own personal NUR repo (NUR meaning Nix User Repository, think of the AUR if you know about Arch Linux).
And once you are at the root of that git repo. You can run nix-build -A ferium to build the ferium package trough nix. If it builds correctly, it should give you a ./result folder with ./result/bin/ferium which is the compiled rust package.
You will probably hit issues with missing dependencies. I see that @leo60228 has added buildInputs = lib.optionals stdenv.isDarwin [ darwin.Security ]; to the ferium/default.nix file. You can try to edit the ./pkgs/ferium/default.nix file with that line to see if it helps you to build and run it properly. I am however having a hunch it might make a differently compiled file, which would break the cargosha256 part. You could replace the hash there with the hash you get from the nix-build output around got: sha256-xxxxxx= at the end.
Hope that can help.
I'm in the final stages of working on a Homebrew formula. I've got it to successfully build and run, and the last steps are to create some tests for it and audit it.
If you'd like me to, I'm happy to maintain the Homebrew package on your behalf, at least for the time being.
Update:
When I started the project, Ferium was on 3.96, and that built and ran fine, but during testing it was failing to parse the Modrinth API properly (error decoding response body: unknown field size, expected one of hashes, url, filename, primary at line 1 column 795), so I tried updating it. On building the updated version, I received the following error:
error[E0658]: use of unstable library feature 'process_exitcode_placeholder'
--> src/main.rs:15:11
|
15 | use std::{process::ExitCode, sync::Arc};
| ^^^^^^^^^^^^^^^^^
|
= note: see issue #48711 <https://github.com/rust-lang/rust/issues/48711> for more information
After some research, I'm presuming that this is because Rust is on 1.61.0, whereas Homebrew is still on 1.59.0, due to some issues Homebrew seems to be having with updating the package (see Homebrew/homebrew-core#98823). Unless I'm wrong about why the error occurred, we'll have to wait for them before Ferium can be on Homebrew.
I'm presuming that this is because Rust is on 1.61
Yes and Ferium uses the latest features
Homebrew is still on 1.59.0
Damn that sucks, yeah we'll have to wait for them then
Also is it possible to install the GitHub Releases binaries by default, and only compile from source if -s is enabled?
As far as I can tell, once you submit the file to the core repository, Homebrew's CI will build binaries ("bottles") for you, you don't provide them yourself.
We might be able to get around that by starting our own tap (something I haven't looked into because it wouldn't be necessary under normal circumstances), but that would be completely overkill since we can just wait.
It seems the issue is that the compiler fails if Rust is built without Jemalloc (rust-lang/rust#92173) but adding Jemalloc pushes the build time to over three days when using GitHub actions, which exceeds some sort of limit, and they're discussing ways to optimise it at the moment.
pushes the build time to over three days when using GitHub actions
Oh damn!
I wonder, how long would compiling Rust and it's dependencies 100% from source take on my potato laptop? A week?
Another update:
I have found that Homebrew's core repository has a policy on "Niche or self-submitted stuff" which says that they will "reject formulae that seem too obscure, partly because they won’t get maintained and partly because we have to draw the line somewhere" so I think a custom tap may be something we actually need. Fortunately, setting up a custom tap is trivial, although providing custom bottles seems to be more complex. I'm also looking into how difficult it would be to automate, since that's something you said should be a thing.
I think we should try to use the GitHub Releases for the tap, and of course compile from source when passed as an option. Then there's no need to separately build bottles
From my limited initial research, bottles have some secret metadata sauce which makes them different from regular binaries.
I have found https://brew.sh/2020/11/18/homebrew-tap-with-bottles-uploaded-to-github-releases/ , but I haven't looked into that extensively yet.
Taps also seem to need to be specially formatted repositories
I have found https://brew.sh/2020/11/18/homebrew-tap-with-bottles-uploaded-to-github-releases/ , but I haven't looked into that extensively yet
I've read that many times, and it's the opposite of what we want. It builds bottles then uploads them to GitHub releases rather than the other way round.
I don't think we can get bottles from the GitHub Actions binaries.
This is another package of ferium, although not maintained by me.
https://aur.archlinux.org/packages/ferium
This is the stable release compiled from source.
Which is different from -git, which is always the newest.
I emailed the maintainer, and requested deletion on AUR because it's unofficial and can be confused with the official packages
Hello, I was looking to package ferium into a .deb for inclusion into the Debian and by extension Ubuntu repositories. I was using the instructions provided by the debian rust packaging team: https://salsa.debian.org/rust-team/debcargo-conf/-/tree/master. I originally tried to package version 4.1.0 using the tooling the Debian team provides, but got error messages asking about missing & too new dependencies. Debian doesn't package octocrab, online, dialoguer, ferinth, furse, or libium (I know those last 3 are sister projects so I would package them as well). I asked for advice in the debian rust packaging team's IRC and they suggested I try to write a patch to get ferium to build against older dependency versions. I tried to dive back in and give it another go today using ferium version 4.1.3 and get another error that the "strip" feature that isn't stable in the 1.56.0 verison of cargo (version packaged in Debian unstable). I'm not sure what the best step forward would be if our goal is to have a native .deb package included in the Debian/Ubuntu repos. I see a couple options from reading and googling, but I'm spitballing here:
- "Cheat" and try to bundle all the dependencies in the deb, but this would all-but eliminate the ability to get the package into the official repositories. Also I don't know what this really gets us over the pre-built binaries in the releases page.
- Wait for Debian to package newer versions of the dependencies and submit missing packages for inclusion. Not sure how long this would take and we'd need a sponsor to get the packages into the repo because I'm not a Debian Maintainer or Debian Developer.
- Give up on a native package for Debian and just advise people to download a binary from releases or from Cargo.
I gave an attempt at packaging ferium for Fedora's COPR which provides rpms for RHEL derivatives (CentOS, Rocky, Alma), Fedora, etc. I think there are similar problems that we'd have to address if we want official packages.
Rust packaging documentation for Debian: https://wiki.debian.org/Teams/RustPackaging, Fedora: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/.
I apologize I don't have much in the way of solutions or answers. I'm not a software developer, just an end-user.
I gave an attempt at packaging ferium for Fedora's COPR which provides rpms for RHEL derivatives (CentOS, Rocky, Alma), Fedora, etc. I think there are similar problems that we'd have to address if we want official packages. Rust packaging documentation for Debian: https://wiki.debian.org/Teams/RustPackaging, Fedora: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/. I apologize I don't have much in the way of solutions or answers. I'm not a software developer, just an end-user.
I got this building on OBS for OpenSUSE (and Fedora for a while) although I ran into a similar issue with Rust 1.61 not being available even on Rawhide Fedora after an update to Ferium.
Rust 1.61 not being available even on Rawhide Fedora after an update to Ferium
I'm also having the same issue with Homebrew. Unfortunately that 1.61 feature is pretty useful because it allows destructors to properly run before exiting
No, not a compile-time error that I was aware of. The helper scripts the Debian rust packaging team provides said that certain dependencies (octocrab, dialoguer, libium) didn't exist as packaged rust debs. I ran the cargo-debstatus crate to check dependencies that were packaged in Debian, output here: https://paste.debian.net/1243842/.
Rust does now have a Ruby file ready to go on Homebrew, but it hasn't been merged yet.
certain dependencies (octocrab, dialoguer, libium) didn't exist as packaged rust debs
But those are Rust dependencies from crates.io, they will be compiled together into the executable. Why should a package manager care about those?
My OBS packages use debbuild to build .debs from RPM .specs, though this would absolutely not be accepted into official repos.
Why should a package manager care about those?
Because if you want a .deb package that will be accepted into official repos you can't just ship an executable with everything already bundled together. It has to be able to be built locally from all the source tarballs of crates without accessing the internet (i.e. crates.io). This means all the crates it depends on have to be packaged and exist in the Debian repos. From the Debian Rust Packaging Policy:
Package builds must not allow Cargo to access the network when building. In particular, they must not download or check out any sources at build time. Instead, builds must use the packaged versions of crate sources, via the corresponding library crate packages, which provide a Cargo directory registry.
Huh, that's extremely weird and annoying to say the least. So how do people upload their Rust packages to debian? Is this why I've never seen any of my Rust tools in apt?
I found this from the Rust CLI book, I wonder if we can just use this
So how do people upload their Rust packages to debian? Is this why I've never seen any of my Rust tools in apt?
Yeah, I would imagine, it can definitely be a PITA. Policy is also similar on most RHEL derivatives to my knowledge, Fedora's policy for example states the following:
Fedora packages SHOULD make every effort to avoid having multiple, separate, upstream projects bundled together in a single package.
All packages whose upstreams allow them to be built against system libraries MUST be built against system libraries. In this case, bundled libraries (and/or their source code) MUST be explicitly deleted during %prep.
Fedora also has specific rust packaging guidelines and provides tooling for packaging crates, much like Debian: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/
If you're curious, you can clone the Debian Rust Packaging team's git here: https://salsa.debian.org/rust-team/debcargo-conf and look through the source folder to see which rust crates they currently package.
https://github.com/theRookieCoder/homebrew-tap
I created a simple tap formula that uses GitHub Releases. No compiling from source or support for platforms other than macOS x64 yet
I found this from the Rust CLI book, I wonder if we can just use this
Good find, I gave it a try and after installing some development packages, I am able to get a binary .deb package after running cargo deb. This package won't adhere to Debian policy, so it most likely won't be allowed in official repos. But if our goal is to just have something good enough for the Github Releases page that people can install with sudo dpkg -i, this should work.
Hey. I'm adding Ferium to Pacstall (pacstall/pacstall-programs#1368), and I noticed you don't have a repology card on your README. Would you be willing to add Pacstall as a method of installing Ferium on your README? I can make the PR if need be.
I'll look into adding the repology card. If your the pacstall PR gets merged I'll be more than happy to add it to the readme!
Alright we merged it!
@Southpaw1496 what do you think?
Yet another package manager, ferium is now available on Homebrew!
https://aur.archlinux.org/pkgbase/ferium-git/
Does anyone have any idea why it can't build in clean chroot?
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!
Damn like 20 dependencies just went poof. Maybe I should go through all the crates and disable unnecessary features...
Oh yeah @JustSimplyKyle both bzip2 and zstd were removed so those are no longer required
@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?
No problem! This kinda flew over iy head, will do!
@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.
@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
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)
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
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.
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 ^^)
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
conflictsandprovidesfields (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 😁
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
conflictsandprovidesfields (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
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)
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 }}Could we also have a version for npm, and also a discord to have better support and contact also
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.
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
@theRookieCoder, you'll get a lot more exposure if you manage to publish to
-
snapand -
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).
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.
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
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 👍