Package Forge: The Lesser Known Snap/Flatpak Alternative Without Distro Lock-In (itsfoss.com)
(Sunday December 21, 2025 @05:34PM (EditorDavid)
from the files-sharing dept.)
- Reference: 0180434271
- News link: https://linux.slashdot.org/story/25/12/21/199237/package-forge-the-lesser-known-snapflatpak-alternative-without-distro-lock-in
- Source link: https://itsfoss.com/pkgforge/
An anonymous reader shared [1]this report from the site It's FOSS :
> Linux gives you plenty of ways to install software: native distro packages, Flatpak, Snap, AppImage, source builds, even curl-piped installers. The catch is that each one solves a different problem, yet none of them fully eliminates the "works here, breaks there" reality across all distros. [2]Package Forge (PkgForge) is a new project with a narrower mission: deliver truly distro-independent portable applications that run the same way across systems....
>
> It's not a new packaging format in and of itself, nor is it trying to replace AppImages. Instead, it's an ecosystem that publishes portable packages and static binaries in curated repositories, paired with a package manager designed to install and manage them. One of the ways PkgForge stands out from some portable app efforts on Linux is its focus on accessible documentation and a security-minded distribution model. The project primarily delivers prebuilt binary packages, keeps transparent build logs, and relies on checksum verification. This helps reduce the spread of ad-hoc install scripts and the need for local compilation, which has long been a common pattern when downloading Linux software directly (and still is for many projects today).
>
> To make life easier for the end-user, the project maintains its own frontend, called Soar... which you can use like an additional package manager, and let it handle installation, updates, and system integration. It also allows you to search for apps and utilities without having to dig through the repos online. Alternatively, you can search the PkgForge repos manually, and download and manage individual portable packages on your own. This is preferable if you're building a portable toolkit on a USB drive, testing a single app temporarily, or simply want full control over where files live...
>
> Even if it doesn't replace Flatpak, Snap, or AppImage, it helps give definition to what a more flexible, truly distro-independent future for portable Linux apps could look like.
[1] https://itsfoss.com/pkgforge/
[2] https://github.com/pkgforge?ref=slashdot.org
> Linux gives you plenty of ways to install software: native distro packages, Flatpak, Snap, AppImage, source builds, even curl-piped installers. The catch is that each one solves a different problem, yet none of them fully eliminates the "works here, breaks there" reality across all distros. [2]Package Forge (PkgForge) is a new project with a narrower mission: deliver truly distro-independent portable applications that run the same way across systems....
>
> It's not a new packaging format in and of itself, nor is it trying to replace AppImages. Instead, it's an ecosystem that publishes portable packages and static binaries in curated repositories, paired with a package manager designed to install and manage them. One of the ways PkgForge stands out from some portable app efforts on Linux is its focus on accessible documentation and a security-minded distribution model. The project primarily delivers prebuilt binary packages, keeps transparent build logs, and relies on checksum verification. This helps reduce the spread of ad-hoc install scripts and the need for local compilation, which has long been a common pattern when downloading Linux software directly (and still is for many projects today).
>
> To make life easier for the end-user, the project maintains its own frontend, called Soar... which you can use like an additional package manager, and let it handle installation, updates, and system integration. It also allows you to search for apps and utilities without having to dig through the repos online. Alternatively, you can search the PkgForge repos manually, and download and manage individual portable packages on your own. This is preferable if you're building a portable toolkit on a USB drive, testing a single app temporarily, or simply want full control over where files live...
>
> Even if it doesn't replace Flatpak, Snap, or AppImage, it helps give definition to what a more flexible, truly distro-independent future for portable Linux apps could look like.
[1] https://itsfoss.com/pkgforge/
[2] https://github.com/pkgforge?ref=slashdot.org
Obligatory xkcd ... (Score:2)
by fahrbot-bot ( 874524 )
[1]Standards [xkcd.com]
[1] https://xkcd.com/927/
Re: Obligatory xkcd ... (Score:2)
by FictionPimp ( 712802 )
This
I'm working on the penultimate solution (Score:3)
by 93 Escort Wagon ( 326346 )
It's called FlatAppSnapImagePortPak - I think you'll love it! Give it a try!
Whut? (Score:4, Insightful)
by karmawarrior ( 311177 )
Neither Flatpak nor Snap, for all their faults, are distro specific. Indeed that's half the fucking point , every app installed using them comes with its own copy of a stripped down operating system.
So perhaps advocates for this crap could start again and explain how it differs from Flatpak and Snap?
Who cares (Score:3)
This is really just advanced stupidity. Use your distro-native package format and be done with it.
Re: (Score:2)
> Use your distro-native package format
Easier for you, perhaps. You only have to deal with what works on your distro. But think of the poor application developers. They have to build against every distro's oddball library configuration. Or build flat-paks and hope that they picked a stable one*.
*Which never happens. Because in the name of security, every other CS grad student has to sneak their new senior project language (Rust, I'm looking at you) into the standard distribution streams.
Re: (Score:1)
...or, for example you're using some paired bit of hardware and software that needs library support that has been obsoleted by your distro and you don't want to run an entire outdated install just to use it.
Re: (Score:2)
Then you compile from sources. Special needs require special skills. Well, not that special, really.
Re: (Score:3)
> Then you compile from sources. Special needs require special skills. Well, not that special, really.
This attitude seems inherently elitist. If we want to see the Year of Linux on the Desktop - and I DO want that - then Linux has to be easier for non-nerds. Hell, I've never compiled from source - I'm sure I could figure it out, but I can't be bothered and I have better things to do with my time.
Standalone options such as AppImage also allow for more choice. For example, I'd give a lot for an AppImage of Thunderbird 115, because its successors are an annoying shitshow put on by developers making stupid and
Re: (Score:2)
Or they just let the maintainers do their work.
You can helpfully provide a "debian" folder and the rpmbuild config that worked on one test system, and all the debian/redhat based distributions take your tarball and then adapt the things you got different from how they do things usually. Creating a simple debian config for let's say a cmake project takes half an hour using cdbs. I bet a debian maintainer would still change things that I got different from what Debian likes to have, but they would be minor ch
Re: (Score:2)
And down here in the real world, distro-packaging is done by the distro, not the upstream developer.
Re: (Score:2)
That's the issue. If I want to write a commercial app for Mac, I only need to make one code artifact, maybe two (amd64/arm64). Windows, I do amd64, love it or leave it. Linux, who knows what a distribution has? In the past, static linking would address this, but as things get more complicated, a standard package ensures that what is needed in the filesystem is there, regardless what is going on with the Linux distribution. It may be that the distribution is extremely bare bones with a userland consisti
Re: (Score:2)
No, I've said for a long time that the Linux distros need to get their act together and either (1) create a packaging format that works everywhere or else (2) pick an existing one and everyone uses that. IMO, fragmentation is the number two reason we don't have "year of the Linux desktop". (The #1 reason is the business world being stuck on MS software and being afraid to try anything different.)
Of course, for a common package format to work then there has to be other commonalities, such as file location (L