18
Will Flatpak and Snap replace desktop Linux native apps?
(www.theregister.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 19 Jun 2023
18 points (100.0% liked)
Linux
2 readers
1 users here now
founded 2 years ago
God I hope not. Especially not snap, it's so painful and slow. AppImage works fine enough I guess. I don't want an ecosystem where more and more developers go with these only and neglect being able to install at a system level.
That is unfortunately the future because maintaining packages for a million different distros is painful to say the least. The best you can hope for is native packages for the top 10 distros. Everyone else will have to deal with flatpak.
Doesn't that just depend on whether or not the people maintaining are happy with the flatpak experience? If they're not, they'd probably keep maintaining their packages.
There are a limited number of build systems and most build systems have some form of dependency management built into them.
Upstreaming modifications so projects can be built using standard build commands is a more monotonous than difficult.
Doing that lets distributions reuse build pipelines accross multiple projects, which simplifies their support burden.
Similarly there are also a limited number of packaging formats and 3 main distributions which most things branch from. Configuring a project to produce an aur, deb & rpm for their base OS layout (e.g. Arch, Debian & RHEL) is again monotonous but helpful to have upstream.
Take an Electron App, this is based on Node.js and will use NPM or Yarn to build and retrieve dependencies.
While both support script extensions, the convention for NPM building and releasing is:
NPM provides libraries to create, aur, rpm and deb artefacts. You would add them as additional scripts, which are called as part of prepublish script (which gets called as part of publish).
There is no reason that can't live upstream.