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.

@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 Oh hey, here's a Ubuntu LTS user asking how to install experimental, undocumented new software: mixxx.discourse.group/t/stems-

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

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

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

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

· · Web · 1 · 0 · 1

@nergal @be @cnx @dredmorbius I’m not sure I understand - flatpak manifests are just JSON (or YAML) build recipes that provide instructions to build an app within the sandbox.

@brainblasted
am going to test that. using github.com/flathub/com.makemkv
never done it before. cannot be talking about something never experienced... let me go experience it right now.
@be @cnx @dredmorbius

@brainblasted
woops! i am using mobile data. cannot undertake large downloads willy-nilly.
will go through the flatpak tutorial instead.
@be @cnx @dredmorbius

@brainblasted @be @cnx @dredmorbius okay. my take as an end operator or user is flatpak are very handy for packages that are near distro-agnostic (goes without saying). how much pressure would this put on other operators and distro packagers? would packager or admin experience added load of in system security? would signing and wot be a solution? may be emphasize and encourage use of keys among regular operators and admins.

also: flatpak is nicely decentralized. flathub, not so much.

@brainblasted @be @cnx @dredmorbius leaving this as something that end operators would choose is a better choice than a distro choosing it as main package management solution. does flathub have mirrors? what p2p distribution solutions are in development for flatpak?

if it is just another package format, it will be another problem for distribution maintainers.

@brainblasted @be @cnx @dredmorbius there was also the year of the flatpak pirate — remember that 1 year?(reddit.com/r/linuxmasterrace/c)

to me this was a demonstration of operator empowerment where a person was not a common user that simply consumed. persons were able to decide how software functioned on their system without much requirements, because flatpak-user is a blessing.

it would be great if flatpak be used like pdf/a is in archiving or maintaining usefulness. imagine resurrecting old games?

Sign in to participate in the conversation
LinuxRocks.Online

Linux geeks doing what Linux geeks do...