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. But being able to package in conventional package managers consumes effort that isn't required to be easy to package in Flatpak.

@alexandra @dredmorbius @rysiek It is required to have maintainable software though.

@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.

@be, @rysiek and @dredmorbius, I'm pretty sure machines running Debian stable don't need new and shiny software at all. I don't use it for development, but it's installed on all the old stuff I throw around the house and the only thing I need them to do is not breaking every now and then. For software not available in Debian's repo I take full responsibility and install them from source. Even when I'm nowhere near being a professional sysadmin, I have standards and Flatpak and Snap are instantly disqualified for anything I need a mental model of.

@cnx @rysiek @dredmorbius "I don't need it" says nothing about the large amount of users who choose to run Ubuntu LTS for whatever reason then are like "how do I install this software you released over a year ago?"

@cnx @rysiek @dredmorbius Oh hey, here's a Ubuntu LTS user asking how to install experimental, undocumented new software:

@be @cnx @dredmorbius yes, getting packaging right is hard. Yes, the problem of balancing stability vs. freshness is hard.

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.

@be @cnx @dredmorbius yeah, but that doesn't solve the problem, it makes it worse!

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.

@rysiek @cnx @dredmorbius Actually, no, that's not a problem with Flatpak, because I maintain the Flatpak and know what versions of libraries it is built with.

@be @cnx @dredmorbius you maintain a flatpak for... what, exactly? A particular piece of software?

Does it depend on other pieces of software? Maintained by other people?

Is it possible that the software you depend on will have maintainer issues sooner or later?

@rysiek @cnx @dredmorbius Yes, I maintain as an upstream maintainer. And yes it has tons of dependencies. And yes some of them have been abandoned, and I forked them.

@rysiek @be @cnx @dredmorbius that's pretty much a definitive non-problem, with both, flatpak and snap (and guix and nix). it's a core part of the toolchain that you know exactly what versions of libraries you're ending up with, even if on the system you may have many different versions installed.

@rysiek @be @cnx @dredmorbius

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 @rysiek @cnx @dredmorbius IME the biggest issue with library versions is users who choose to use outdated operating systems continuing to be affected by bugs in libraries that have already been fixed and released.

@meena @brainblasted @rysiek @cnx @dredmorbius I don't think most people are forced to use OSes that only release every 2 years.

@be @brainblasted @rysiek @cnx @dredmorbius Elementary follows Ubuntu LTS, and I've actually quite enjoyed not having to debug why X or audio is breaking every two weeks 🤷🏻‍♀️

@meena @be @cnx @dredmorbius there’s nothing wrong with using an older, stable distro imo. The problem comes when people on those older distros want to use newer programs.

That said, I think elementary is diverging quite a bit from Ubuntu since the AppCenter and default app set are flatpaks.

@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.

Cc: @brainblasted, @rysiek and @dredmorbius

@cnx @rysiek @brainblasted @dredmorbius Debian can say that all they want, but it doesn't change that lots and lots of people want to run software on old OSes.

Then they are wrong, @be, and you can tell them that you do not support such configuration. Cc: @rysiek, @brainblasted and @dredmorbius

@cnx @rysiek @brainblasted @dredmorbius To be clear, it's mostly Ubuntu LTS users that bother upstreams for issues that have already been fixed.

@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.

Cc: @rysiek, @brainblasted and @dredmorbius

@cnx @be @dredmorbius @rysiek you still haven’t really answered the question: why should we if we can and want to support users on different OSes? And when we can do it easily with flatpak?

@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.

@cnx @brainblasted Uhm, what. None of that seems congruent with reality IME.

@cnx @be But the problem is, as mentioned, users want the latest software. And contributors shouldn’t need to switch distros when it’s perfectly viable to build on their own via flatpak.

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 @cnx @dredmorbius

@nergal @be @cnx @dredmorbius flatpak already does not work on bsd because it uses linux-specific features.

As for requiring newer versions, apps can already do that. As far as I'm aware, though, this hasn't been much of a problem.

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

Show newer

@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? :thaenkin:

Anyway, that a fun discussion and you guys should continue having it, but please untag me. Thanks.

@cnx @be @dredmorbius @rysiek Why urge them not to use our software when they can use it just fine via flatpak?

@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.

Cc: @be and @dredmorbius

@cnx @be @dredmorbius @rysiek

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 it's a case of flatpak/snap developers being "so preoccupied with whether or not they could, they didn’t stop to think if they should", to quote a classic.

@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.

@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.

@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.

@rysiek @be @cnx @dredmorbius Software can be outdated even on the newest version of a distro. Distros like Solus hold applications back or refuse to package them for arbitrary reasons.

@rysiek @be @dredmorbius this is really, really inaccurate IMO. There are plenty of times that software is hard to package due to reasons outside of the software itself:

- Software in e.g. Rust or Python or Haskell often needs a decent # of deps that all need to be packaged individually
- You can't easily use useful libraries (e.g. Abseil) that don't promise ABI stability without asking for exceptions
- You have to target language tooling and runtimes for the oldest distro you support. Want to use Python 3.7 features? Too bad, one of your target distros only ships 3.6.

@refi64 @rysiek @be @dredmorbius not just language features, but features in general. There are developers I’ve seen who want to use libadwaita for example, but don’t because the oldest distro they support won’t package it for a long time.

@be Fanatical packaging systems (within reason) strongly assure well-behaved software.

Dependencies are managed. Configurations are preserved. Bugs are tracked and prioritised, including packaging bugs (which can be release-critical). Standards are imposed and enforced (notably for documentation).

Well-packaged software should, of course, be distrubutable by other packaging formats. That's a given. But to say that a packageing format or method can produce well-behaved packages is inverting causality and looking through the wrong end of the telescope.

Good packaging systems prevent and minimise suce effects. Bad software is exposed by virtue of the fact that it cannot comly with good packaging requirements.


@dredmorbius I'd be interested, I have a list of good and bad parts of NixOS

@shapr I've not used NixOS.

I doubt you'd find anything I had to say particularly edifying.

Sign in to participate in the conversation

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.