Gah, how I hate Flatpak.
It insists on downloading all the packages I already have installed on my base system anyway, plus insists on installing stuff into the root partition instead into my home diretory.
All sorts of utterly annoying and otherwise avoidable frustrations ensue.
Flatpak and Snap should both just DIAF.
@rysiek There's a flavour of argument over packaging systems and formats which runs:
X package format is difficult for software developers to use.
Y package format is easy for software developers to use.
Therefore Y package format is better than X.
What's not realised is that the fundamental value and benefit to package management is to systems administrators / owners / users, and integrated distributions of packages. And that the major costs of operation and maintenance are not installation, but *operations and maintenance.
"Easy for sofware developers" typically translates to "encourages sloppy and difficult-to-maintain processes and practices". Not only this, but by lowering up-front costs at the expense of long-term costs, the practice further encourages poor practices (from an O&M perspective), and puts well-behaved software at a disadvantage.
See the Debian Project's explicit focus on user benefit, a long-term value benefit.
This is a Jevons Paradox / Gresham's Law crowding out of well-behaved software and a race-to-the-bottom of poor long-term O&M behaviour.
#Linux #PackageManagement #OperationsAndMaintenance #JevonsParadox #GreshamsLaw #Flatpak #snap
@dredmorbius @rysiek Well behaved software is not at a disadvantage with Flatpak. If software is easy to package in conventional distro package managers, it is easy to package in Flatpak.
@be @dredmorbius If software is easy to package in conventional distro package managers, Flatpak is unnecessary.
@rysiek @dredmorbius It's still helpful for people who choose to run out of date operating systems for whatever reason.
@cnx @rysiek @dredmorbius Oh hey, here's a Ubuntu LTS user asking how to install experimental, undocumented new software: https://mixxx.discourse.group/t/stems-function-in-mixxx/23393/8
@rysiek @cnx @dredmorbius Unfortunately moving to a newer version of Ubuntu wouldn't help in this case because the maintainers of the Debian package don't respond to notifications of new releases.
@rysiek @cnx @dredmorbius Not really; it's significantly easier to write and maintain a Flatpak manifest than all the stuff Debian requires for packaging, then repeat that for a bunch of dependencies.
@be @cnx @dredmorbius ah, so now every package maintainer is supposed to maintain a separate set of dependencies *just* for that particular package?
How many times will I have the same version of KDE/Qt/GTK installed on my system, then? How much diskspace will that take?
@rysiek @cnx @dredmorbius No, I forked those dependencies so packaging them for macOS & Windows wasn't a giant pain in the ass... which also makes them trivially easy to use in Flatpaks.
@rysiek @cnx @dredmorbius You don't have to reinstall large libraries like Qt and GTK for every Flatpak because that's what Flatpak runtimes are for.
@be @cnx @dredmorbius okay, but with dependencies that do not go into "runtimes", based on what you're saying, one can end up with the same version of a particular library installed mutliple times because multiple people forked the same abandoned flatpak package.
Great, so now I have not one package to audit if I need some basic assurances, but multiple. For the same piece of software.
@be @cnx @dredmorbius well that's going to be the same with the maintainer of a flatpak/snap packages, so that's going to be a problem regardless of a packaging system in use.