@rysiek There's a flavour of argument over packaging systems and formats which runs:
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.
> Easy for software developers
see, in my opinion arch AUR packages are "easy for developers" because they're just shell scripts that get the source repo and put together an archive of files, which can 'in theory' build on any computer
while debian packages are harder for developers because they absolutely require multiple stages of things tailored for specific debian tools and usually a special .deb file host
-i don't use plain 'arch btw' and never have-
@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.
@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
@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.
@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.
“Easy for sofware developers” typically translates to “encourages sloppy and difficult-to-maintain processes and practices”.
I don’t think this is a correct assumption. What do you define as “sloppy processes” encouraged by flatpak? Just because it’s easier for a developer to ship their application doesn’t mean it’s they aren’t putting care into it.
On the internet, everyone knows you're a cat — and that's totally okay.