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.
@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
But that user chose LTS for a reason. If that reason doesn't hold anymore, one can always move to a fresher version of Ubuntu, for example.
Flatpak and snap are not solutions here, they are hacky work-arounds. In the long run they will, IMVHO, cause more problems than they solve. For one, because they break basic assumptions about how software is installed and run on a given system.
@rysiek @cnx @dredmorbius @cnx @rysiek @dredmorbius People do this all the time. Sure maintainers could say, well, you're choosing to run an out of date OS -- with package maintainers that don't respond to us when we tell them about releases -- deal with it or build from source. The reality is then most of them would ask for support for old versions, resulting in annoying questions about bugs that have already been fixed, not change their distro.
Now the user has multiple different versions of the same library installed, and debugging which one got loaded at any given time is going to be hell. Especially with a non-techie user, which seems to be *the* target group for flatpak/snap.
Basically, it means the few important assumptions one could make about a given system just fly out the window.
Now the user has multiple different versions of the same library installed, and debugging which one got loaded at any given time is going to be hell.
You haven’t debugged with flatpak, I see. You just install the debug symbols for the SDK and the app with a simple flatpak install, run gdb within the app sandbox, and then remove the debug symbols when you’re done. The multiple versions of the libraries don’t conflict with each other at all. And you always know what library you’re using: either the version in the SDK you use, or the one the developer has explicitly in their flatpak manifest.
@rysiek @be @cnx @dredmorbius If anything, it’s more difficult as a developer when you don’t know what version of a library the user has on their distro. Their distro could be shipping a bugged version, a version with patches that are causing problems, or the library could have changed ABI and the distro didn’t (or couldn’t) rebuild your app to account for it - which has happened on an app I’ve contributed to.
@brainblasted, I believe it’s better for the overall ecosystem if upstream just decline support for users of older distros (releases) and encourage them to upgrade their OS and getting involved in downstream packaging. The fragmentation and outergration Flatpak and Snap cause hurt end-users more than their benefits (e.g. input-method-related issues, upgradability) and upstream has limited resource for handling integration problems. I don’t think I can convince you or @be or the other way around do let’s end this discussion here.
@be, please see Debian wiki for the counter argument if you haven’t already. As a developer, you can simply urge whoever reached you upstream to not attempt to use your software with Debian stable, or wait until the next release when your software is packaged downstream.
It’s also worth mentioning that via Debian’s policy users are not supposed to file bugs to upstream but report to the distro’s mailing list instead. Don’t try to take too many responsibilities, it’s not your job to warrant the end-users’ experience.
@be, I think you could say the same to the users of Ubuntu LTS. It’s not your job to be someone’s personal sysadmin; wouldn’t it be better for everyone if you can focus your energy on writing good software?
My point is, instead of pinning every single library, give people a list of supported OSes. If they want to use your software on unsupported platforms, they are on their own and should seek help from their distribution, whose job is to distribute software, including the ones you maintain.
@brainblasted and @be, you will need to work with downstream maintainers, but please do not expect your software to be available to your users instantly (i.e. it will be available the next distro release, whenever that is). Contributors will adapt to your software’s requirement and probably use a cutting edge distro anyway.
what of bsd? what of systems with different init? will it be a problem in future if flatpak versioning comes into question? will there eventually be "works only through flatpak version ≥ x"? guessing virtualization will be the goto solution then?
@be @mastodon.technology @cnx @dredmorbius
in order to preserve source availability, what effect would putting compilation into the flow of installing a flatpak have? meaning, instead of only shipping binaries, offer the option of also compiling elements of the manifest locally. that way, concerns about confidentiality of parts may be allayed?
@be @cnx @dredmorbius
am going to test that. using https://github.com/flathub/com.makemkv.MakeMKV/blob/master/com.makemkv.MakeMKV.json
never done it before. cannot be talking about something never experienced... let me go experience it right now.
@be @cnx @dredmorbius
@be @cnx @brainblasted @dredmorbius I wonder if that's somehow related to the stability of those "old OSes", which in turn comes at a price of them moving slower than the break-neck pace of the "move fast and break things" tech industry?
Anyway, that a fun discussion and you guys should continue having it, but please untag me. Thanks.
@brainblasted, because (1) you will need to take responsibility on all dependencies you ship recursively, which is duplicated effort for all Flatpak or alike maintainers and I doubt it’s within your expertise (were it be, you would be package your software properly downstream) and (2) you will be giving users like @rysiek confusions as Flatpak packages don’t work the same way the rest of the system does.
were it be, you would be package your software properly downstream
I’ve done “downstream” packaging before. It’s frustrating. People far smarter than me find it annoying. It’s a false assumption that people are using flatpak because they don’t know how to make distro packages.
As for things not working the same, that’s something to be resolved over time via portals.
@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.
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.