Did I just solve the packaging problem? (please feel free to tell me why I'm wrong)

MonkderDritte, 19 days ago

Different library versions etc.

ulkesh, 21 days ago

The way I see it, the issue here is that everyone is trying to solve packaging from the developer perspective. I understand why they do, but the only way to solve this is to instead look at it from the user’s perspective.

Apps should be dead simple to find, dead simple to install, dead simple to maintain and use, and dead simple to remove.

This is why snap and flatpak and appimage are things. The problem here is that they each have various issues within them that break one or more of those tenets from the user’s perspective.

Trying to resolve packaging by going back to same methods that have existed for decades and wrapping them in a bow may help developers in some fashion, but the end users are still going to lament dealing with apps on Linux because it’s not solved — for them.

digdilem, 21 days ago

I like this perspective, but it’s the developers who get to choose in the world of FOSS software, and I suspect most would rather develop than package.

Learning the different formats, methods and then committing to re-packaging every update for eternity when you’re often a single person or a very small group is a big ask on top of developing the software too, so they’re going to select a method that’s easiest for them.

So if there was a user-led method, it would still need to appeal to developers as well.

Max_P, 21 days ago

The problem is that you can’t just convert a deb to rpm or whatever. Well you can and it usually does work, but not always. Tools for that have existed for a long time, and there’s plenty of packages in the AUR that just repacks a deb, usually proprietary software, sometimes with bundled hacks to make it run.

There’s no guarantee that the libraries of a given distro are at all compatible with the ones of another. For example, Alpine and Void use musl while most others use glibc. These are not binary compatible at all. That deb will never run on Alpine, you need to recompile the whole thing against musl.

What makes a distro a distro is their choice of package manager, the way of handling dependencies, compile flags, package splitting, enabled feature sets, and so on. If everyone used the same binaries for compatibility we wouldn’t have distros, we would have a single distro like Windows but open-source but heaven forbid anyone dares switching the compiler flags so it runs 0.5% faster on their brand new CPU.

The Flatpak approach is really more like “fine we’ll just ship a whole Fedora-lite base system with the apps”. Snaps are similar but they use Ubuntu bases instead (obviously). It’s solving a UX problem, using a particular solution, but it’s not the solution. It’s a nice tool to have so developers can ship a reference environment in which the software is known to run well into and users that just want it to work can use those. But the demand for native packages will never go away, and people will still do it for fun. That’s the nature of open-source. It’s what makes distros like NixOS, Void, Alpine, Gentoo possible: everyone can try a different way of doing things, for different usecases.

If we can even call it a “problem”. It’s my distro’s job to package the software, not the developer’s. That’s how distros work, that’s what they signed up for by making a distro. To take Alpine again for example, they compile all their packages against musl instead of glibc, and it works great for them. That shouldn’t become the developer’s problem to care what kind of libc their software is compiled against. Using a Flatpak in this case just bypasses Alpine and musl entirely because it’s gonna use glibc from the Fedora base system layer. Are you really running Alpine and musl at that point?

And this is without even touching the different architectures. Some distros were faster to adopt ARM than others for example. Some people run desktop apps on PowerPC like old Macs. Fine you add those to the builds and now someone wants a RISC-V build, and a MIPS build.

There are just way too many possibilities to ever end up with an universal platform that fits everyone’s needs. And that’s fine, that’s precisely why developers ship source code not binaries.

Shareni, 21 days ago

standards

Also, different solutions have different benefits and downsides, and are better in different scenarios.

krolden, 21 days ago

install gentoo

Fredol, 21 days ago

I can’t believe sometimes I am part of the same community as people like you

MrSoup, 21 days ago (edited 16 days ago)

The universal packaging problem is having all the dependencies for all the software, making it all available for end users, in one place and easily make those packages for virtually every distro by developers wanting to target Linux systems. A lot of companies do not support Linux for this reason: there is no one single format to distribute software (not considering tar.gz).

Having a tool that convert packages to other distro’s package format does not solve this, it’s just a long chain which original devs of a software are not in control of. The idea of Flathub and Snapcraft (the repos, not flatpak/snap) is to make one place for third party devs to publish their software (foss and not).

Also, flatpak is trying to make a “standard” api to interact with the host system thru the sandbox for privacy/security reasons (like android).

theshatterstone54, 21 days ago

Yeah, but

1. Using a tool that allows you to build using OBS once, and distribute for all distros is already a solution that makes it possible to target all of Linux.
2. Flatpak’s sandbox isn’t really doing much for security/privacy as addressed by this: flatkill.org/2020 (Main concerns relate to pretty much every app escaping the sandbox making the sandbox essentially useless, and concerns that application runtimes bundled with flatpak are far less likely to be updated and patched than dependencies on your host system, and runtimes often actively contain security holes that are unpatched for runtime versions still used by applications.

BUT BUT

I have to agree that if it gets companies to support more Linux software, then I’m sure we can deal with it. HOWEVER, there is another issue, the issue of confusion. After all, isn’t one of the main reasons for trying to get more software on Linux, to use that software to get more people to use Linux? For that we need a more user-friendly approach, we need to figure out how to get less permissive, well, permissions, to applications, as well as to apply system theming by default (I know theming is controversial with the whole “don’t theme my apps” debacle but I think it would be great to have

AND YES, this post was mostly an experiment to see what people think and how they’d react to differing opinions different from the status quo. I’m actually team Flatpak. I think what Ubuntu has recently done to improve Snap speeds is great (now if only all the apps on Snapcraft updated to implement it all), but almost no apps have taken advantage of it. AppImage shows some promise in its simplicity, but that sacrifices a lot of usability and makes a lot of the improvements seen in snap and especially in Flatpak near-impossible (for example theming and .desktop file support).

I’ll be honest, probably the only issues I have with flatpak are:

1. having to type the whole thing. What I mean is running “flatpak run one.ablaze.floorp” instead of just “floorp”, for example. How about we do away with the whole “org.ablaze.floorp” and make it possible to just use “floorp”, the same way you can do that during an installation! If it’s been implemented for “flatpak install”, why not “flatpak run”, and even better, why not make it into some sort of alias, where you can run, say, “floorp-flatpak” from Terminal or a Run launcher?
2. Flatseal. I mean, Flathub has THE control center for Flatpak apps and nobody has taken it upon themselves to make this more official (this should be like a standard package imo).
3. Also for Flatseal specifically, can we make it easier to theme (gtk and qt) apps, (like a dropdown or something?) instead of having to look up the envvar name because I can’t remember it?
4. Can we find a way to force apps that don’t really need full filesystem permissions to remove that? Maybe just have certain user folders, like Downloads and Pictures instead of the entire home directory as most apps simply don’t need this level of access? Maybe make the Flathub team decide on a case by case basis if the app really needs all that access and ask the dev to restrict that as a requirement for being added to Flathub? If you claim to offer security and privacy, might as well prove it.

I think that’s about it.

MrSoup, 21 days ago (edited 16 days ago)

1. Using a tool that allows you to build using OBS once, and distribute for all distros is already a solution that makes it possible to target all of Linux.

There are projects using this method, but bigs like BlackMagic would prefer shipping one package (like he does right now with DaVinci Resolve). Anyway, after installing a package downloaded from a site, how do you update it? Who publish that software should make a repo for every package type or making app update itself (like apps on Windows do).

Flatpak’s sandbox isn’t really doing much for security/privacy as addressed by this: flatkill.org/2020

Thanks for the link, I was aware of those issues but wasn’t aware of this website. Anyway, the major issue here is old bundled libraries, with further spreading of flatpak other issues should be trivial to fix, I hope.

we need to figure out how to get less permissive, well, permissions, to applications

Libportal should fix this.

as well as to apply system theming by default

My flatpaks apps follows system theme by editing global vars, there are a bunch of guides to do it. Distros could add them by default, but (as you said) theming is still controversial.

AND YES, this post was mostly an experiment to see what people think and how they’d react to differing opinions different from the status quo.

Next time just ask. Would make more people engage in commenting rather than just downvoting.

having to type the whole thing. What I mean is running “flatpak run one.ablaze.floorp” instead of just “floorp”, for example.

That’s to avoid conflicts, flatpak install looks up for entries that’s why you don’t have to write the whole thing.

Flatseal. I mean, Flathub has THE control center for Flatpak apps and nobody has taken it upon themselves to make this more official

What flatseal does is giving a GUI for configuring flatpaks, you can just use flatpak command itself from cli (that’s the official way). That should be embedded in system settings (gnome-control-center for gnome).

Also for Flatseal specifically, can we make it easier to theme (gtk and qt) apps, (like a dropdown or something?) instead of having to look up the envvar name because I can’t remember it?

This is entirely feasible, try ask flatseal devs by opening an issue.

Can we find a way to force apps that don’t really need full filesystem permissions to remove that?

Maybe like Android does: first time you open an app it asks you to grant permissions to that app without giving them all the permissions it asks by default. That way you can just opt which permissions would like to give to an app on installation or first launch, tho this is not what happen right now because can entirely break some apps so it’s up to power users to tweak it.

joojmachine, 21 days ago

Can we please, in the year of the lord and savior, stop linking to flatkill for once? They have been debunked at least 5 different times at this point, so let me link to a couple of them: …gitlab.io/…/Flatpak-an-insecurity-nightmare/

…gitlab.io/…/response-to-flatkill-org.html

Some of your points aren’t bad, just not up to date to what most of the ecosystem has been doing for a while now.

coolmojo, 21 days ago

FlatPak and snaps are not only solving the universal packing problem, but in addition: providing necessary libraries which are not present on the main system; an be installed on multiple architectures (x86, arm, etc); sandboxed.

thingsiplay, 21 days ago

Why would PKGBUILD solve the issue? The packaging issues are still the same, as every distro has different package names, revisions and not all packages in their repository. The dependencies are not solved with this.

thfi, 21 days ago

If at all, you want to use Gentoo’s ebuild system, which can be seen as some kind of superset of PKGBUILDs. I guess one could write a Python script that “dumbs down” ebuild scripts to PKGBUILDs for simple packages (excluding complex stuff like kernel, KDE, …). The main challenge, as pointed to before, would be maintaining a table mapping package names between distributions in order to get the dependencies right.