PkgForge-Dev is a sub-organization of PkgForge. It exists to package software that ships no portable build of its own, which in practice means AppImages: several hundred of them, one repository per application, each maintained by whoever cared enough to make it.
They are not tied to us. Download one and it runs, or install it through soar, which pins these releases like any other upstream.
Anylinux-AppImages, @Samueru-sama's project, is the index of everything built here and the explanation of why it runs anywhere. Most of what is in this org follows from it.
The short version: these bundle their dependencies rather than borrowing the host's, so they work on musl and glibc alike, and on distributions far older than the machine that built them. The uruntime mounts with FUSE when it can, falls back to user namespaces when it cannot, and extracts and runs when neither is available. There is nothing to install first, including on NixOS.
The parts the AppImages are built out of, useful on their own:
| Project | Description |
|---|---|
| Anylinux-sharun | Collects an application's libraries next to it and rewires it to use them, which is what makes the result independent of the host. |
| Anylinux-uruntime | The runtime the images ship, cut down to DwarFS only and widened to more architectures. Forked from VHSgunzo/uruntime. |
| appimagetool | A Rust implementation, targeting DwarFS and the static runtime rather than the original's assumptions. |
| AppImageUpdate | Updates an AppImage over zsync, fetching only the parts that changed. |
| archlinux-pkgs-debloated | Stripped-down Arch packages, which is most of why these images are smaller than the alternatives. |
- Package something. If an application ships no portable build, it belongs here. How to make these walks through it, and there are several hundred existing repositories to copy from.
- Fix one that broke. Upstream moves, builds rot. Open the issue on the repository it happened in, not here.
- Improve the tooling.
sharunandappimagetoolare where a fix helps every image at once.
AI-assisted contributions are welcome. We do not ask what wrote your patch, and the answer is not held against you. What matters is whether it is correct, whether you understand it, and whether you ran it. That is the same standard a hand-written patch meets.
It does rule out four things:
- Read what you send. A pull request you have not reviewed, cannot explain, and did not test is not a contribution. Volume does not substitute for any of the three.
- Do not open issues you have not reproduced. A generated bug report costs more time than a bad patch, because the behaviour it describes may never have happened.
- Do not send generated security reports. A plausible vulnerability that does not exist takes attention away from one that does. Report what you have confirmed.
- A build recipe you have not run is a guess. Invented URLs, versions and dependency lists all look plausible and none of them build. Run it, launch the result, and say which distribution you launched it on.
None of this is specific to AI, and we would ask it of anyone. AI is just what made it cheap to produce work that skipped all four, which is the only reason it needs saying.
PkgForge Discord
`➼` https://discord.gg/djJUs48Zbu
