Package Forge: The Lesser Known Snap/Flatpak Alternative Without Distro Lock-In (itsfoss.com) 49
An anonymous reader shared 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. 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.
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.
Who cares (Score:3, Insightful)
This is really just advanced stupidity. Use your distro-native package format and be done with it.
Re: (Score:3, Insightful)
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:2, Insightful)
...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:3)
Then you compile from sources. Special needs require special skills. Well, not that special, really.
Re: (Score:3, Insightful)
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)
Then you compile from sources. Special needs require special skills. Well, not that special, really.
This attitude seems inherently elitist.
Bullshit. Want to use a tool? Be competent to use it. There is really no excuse and your AdHominem is just complete nonsense.
In the case of Linux, use a distro that matches your level of skill.
Re: (Score:2)
You totally ignored jenningsthecat's point that this means we'll never see the Year of Linux on the Desktop. So no, his "AdHominem" (sic) is totally apropos (not to mention that it isn't an ad hominem in the first place).
Re: (Score:3)
His point is nonsense. If we see Linux on many more desktops, it will be via a small number of distros.
Re: (Score:2)
Re: (Score:2)
Nope. Don't be an idiot.
Re: (Score:2)
Re: Who cares (Score:2)
Currently there are more things not working on Windows - included, but not limited to old hardware support - thannnot working on Linux.
TYOTLL isn't delayed by Linux features, workflow or user friendliness itself.
Re: (Score:2)
One popular thing that works on Windows and not on Linux is Apple Mobile Device Service. This is the component of iTunes that lets a user sync MP3 albums, such as those bought on itch.io or Bandcamp, onto the Music app of an iPhone over a USB cable. As a driver, it is outside the scope of Wine.
Re: (Score:2)
I suppose I could dig up the source of an earlier version of TB and try to compile if for my existing system - with no strong assurance that it's even possible.
Oh, man. I've been there - you really don't want to do that.
I used to build Firefox and Thunderbird from source because, at least at the time, that was the only way to get them to work with the OS X password manager (at least I think that's why I was doing it... it was a LONG time ago). But compiling the Mozilla products on OS X required other packages, which (again, at least at the time) ALSO had to be built from source... plus there were particular flags you had to feed to gcc/clang/whatever for it to not
Re: (Score:2)
Re: (Score:1)
This is completely ignoring the fact that sometimes a simple rebuild is far less than the necessary minimum amount of work; sometimes the software would need heavy overhauling to bring it up to compatibility. Don't think I didn't notice your attempt to astroturf over the real issues while also trying to make me look like someone who can't read a README file. I can compile a kernel, I can even wrangle a simple patch here or there when the issues are obvious, but porting forward strategically obsoleted gles2
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)
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.
Provided your application already has enough users compiling it from source code to justify packaging it in the first place.
Re: (Score:2)
The easier it is for a maintainer, the fewer interested users are required to motivate one. In the best case, the package is used by the maintainer themselves, then it doesn't matter at all if it has any further users.
It needs to be in a well-known distro first (Score:2)
Until the maintainer receives an issue report requesting a package for a particular distribution. For every one report, there are probably dozens of cases where another prospective user considered using a particular piece of software but did not because there was no package.
I read Package Forge's inclusion criteria [pkgforge.dev]. In order to get distributed in PkgCache, the application first needs to "be a well known package" and listed on a website called Repology [repology.org]. And Repology's inclusion criteria [repology.org] appear to be meant fo [repology.org]
Re: (Score:2)
And down here in the real world, distro-packaging is done by the distro, not the upstream developer.
Re: Who cares (Score:1)
false, the distro package maintainers do that for good distros and that includes the BSD as well as GNU/Linux. There is mostly no problem.
Re: (Score:2)
What do you do if your app builds just fine with one distribution but not another? Isthat the responsibility of the distribution maintainers? Or the application developers?
What do you do if Debian makes systemd a dependency but other distros say, "Fsck you! We're not including that garbage." Or Wayland. The app developers just sit back with their popcorn and watch the fight?
Enter the flatpack. Bundle everything together and create a stand-alone installation. Down side: The motivation to keep flatpacks up
Re: (Score:1)
flatpack makes a pile of bloat and has less effort at polish than what the distro maintainers do for the commonly use (thousands of them!) programs
Yes, app developers do basically just that, the distro maintainers know the quirks by now and make it work. I use openbsd for servers and Linux Mint for desktop and there is no problem for all the thousands of common wares that most use. At work SLES and that's also the case. No problems!
Re: (Score:2)
Re: (Score:2)
So use a container if it's that much of a problem.
Just bring your dependencies with you.
Re: (Score:3)
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)
AppImage seemed to be the best solution...
AppImage has proven itself to be a huge disappointment, and I suspect the same holds true for the others as well. I was running Kdenlive on Kubuntu 20.04, and there were must-have features in a newer Kdenlive that required a newer Kubuntu, so I downloaded the last AppImage of the Kdenlive I needed.
When I tried to run the AppImage, it failed with a GLIBC dependency error. That, for me, completely killed the whole notion of AppImage, SNAP, and all the others. They need the entire dependency chain (essentially
Re: Who cares (Score:2)
Distro maintainers do that, for good distros and wanted apps. as dev write for one major distro.
Yeah, about that.. (Score:2)
On Windows, most software developers cannot even implement proper update mechanisms for their software, and many still insist on supplying EXEs instead of clean MSI/MSIX packages which can be managed automatically in a native way. When it
Re: (Score:2)
> Ideally it would be nice to just have one executable to run without the need to install everything
Agreed, but it's virtually impossible to actually do this. libc shouldn't be statically linked (it's pretty pointless if you try) and seems to be intrinsically part of the running OS, and so you end up relying on whichever one the distro has. You then end up compiling your single binary for every major release of every distro you want to support. If you want to support x86 and ARM, then you've got to do a
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
Re: (Score:2)
What problem would static binaries solve? Dependencies? Flatpak and Snap already solve that pretty well while avoiding most of the disadvantages.
Re: (Score:2)
I'm on Devuan. Most Debian packages work but not all. When one doesn't I use the appimage or flatpak, preferably the former. It gets me the software and I move on. Right now I am using OrcaSlicer from a flatpak.
Obligatory xkcd ... (Score:5, Insightful)
Standards [xkcd.com]
Re: Obligatory xkcd ... (Score:2)
This
What about integrating with native PM? (Score:2)
I came here to make sure the above comment was already visible, but I also sat and thought for a moment. What would be the real solution versus "invent + 1" solution too...
What about a layer that interacted with each local package manager? Basically an easily installed wrapper for any native package manager. It wouldn't do everything the native managers did, but it could offer synonyms between them (RPM names = DEB names) to let people use the terms they're familiar with.
No it isn't solving 100% the same
Re: (Score:2)
"synonyms between them (RPM names = DEB names)" But are they really synonyms? That is, can the RPM module do exactly the same thing the DEB module does?
(I've never programmed anything for Linux that required a UI, and I only ever targeted a single kind of Linux. So I'm asking from the standpoint of not knowing, not from disagreeing.)
I'm working on the penultimate solution (Score:5, Funny)
It's called FlatAppSnapImagePortPak - I think you'll love it! Give it a try!
Whut? (Score:5, Informative)
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?
Re: (Score:3)
In theory you can host your own Flathub alternative, for software that Flathub rejects, but not for Snap. So Flatpak is more distro-neutral then Snap.
But yeah, any suggestion that Flatpak is "distro lock-in" is plainly wrong.
winget for Linux, oh dear! (Score:2)
The reason why winget works for Windows is because it makes life easier without upsetting the broken status quo. That being every application bundling its own Electron, GTK, Qt
Some of us still know how (Score:3)
./configure
make
make install
Maybe FreeBSD has the right idea? (Score:2)
I am about to switch from Linux to FreeBSD. I have used FreeBSD before, and I really liked their package management, among other things.
And hilarity ensues (Score:2)
And thus Snap, Flatpak, AppImage and now this was inflicted onto the world, all solving the problem while not solving the problem.
Re: (Score:2)
This. [xkcd.com]
Distro maintainers need to resist the urge to include every senior class project.
You want Rust? No problem. It's on the server, right next to Smalltalk.
Containers (Score:2)
Doesn't containerization solve all of these problems? Might have a bit of overhead, but not as much as a full hypervisor stack.