Flatpak politics getting out of hand?

[Phishfry]

Making software is easier than distribuiting it.
My first lesson of that was learning tcl/tk programming making an application and then trying to distribuite it without the programming language installed.
A tcl runtime executable. So you need starkit or freewrap.
It all seemed stupider than I thought imaginable.
Why was making a 'script to runtime' executable so hard and depending on other programs (packagers).
Maybe it was just me and wrongthink. I did not want to fight dependencies and just build it in.

Tcl/Tk Starkits

 

[cracauer@]

Making software is easier than distribuiting it.
My first lesson of that was learning tcl/tk programming making an application and then trying to distribuite it without the programming language installed.
A tcl runtime executable. So you need starkit or freewrap.
It all seemed stupider than I thought imaginable.
Why was making a 'script to runtime' executable so hard and depending on other programs (packagers).
Maybe it was just me and wrongthink. I did not want to fight dependencies and just build it in.

In the history of programming languages and their acceptance it always played a major role whether you could "just make an executable".

It is one reason why SBCL can save its whole loaded environment with libraries into one (big) ELF executable. It increased acceptance a lot.

Scripting languages distributed in a straightforward manner also have the problem of automatically giving out the source code.

 

[GlitchyDot]

Sigh... just recently, I came across a news item that I'd like to get people's opinion on...

OBS Studio Raises Issues With Fedora's Flatpak Package - Phoronix

www.phoronix.com

Reading through the article, it involves OBS Studio (Packaged as multimedia/obs-studio on the FreeBSD side of things), but it really seems like any other Open Source project could fall victim to this kind of spat.

I have called out poor packaging in FreeBSD before: Thread sienna_cichlid-driver.86670

We have a rather active thread about pkg 2.0 issues: Thread pkg-2-0-0-problems.96540

We do have lots of debates of pkg vs ports (Looking for such threads is left as an exercise for the reader).

We do have occasions when a port maintainer ended up letting the port expire after putting in lots of effort into trying to make it work on FreeBSD: math/sage is marked as an expired port. The same maintainer is still active on other ports (he's maintaining math/rkward).

We do have the Porter's Handbook as the official, definitive guide to getting a FreeBSD port of software published. As long as a dev has the patience to make sure the software still works after correctly following instructions in Porter's Handbook, and it's not under a license that makes such publishing impractical (illegal copy of something like metin2), software can be packaged for FreeBSD.

What has me shaking my head is the sheer pettiness I'm seeing in Linux camp... What I say next will only make sense to someone who actually read the Phoronix article I linked to.

I think it is understandable for a project like Fedora to want to prioritize their own packages over upstream. But if a piece of software is broken in the official repos, it really should be up to the user to be able to get the software from elsewhere, be it Flathub or Github or whereever. It does sound like it got ugly over specifically packaging between OBS Studio and Fedora. If Fedora wants to offer its own packages of OBS Studio, I do see it as responsibility of the Fedora project to properly package OBS.

Properly packaging software is a lot of work - which is why FreeBSD relies on volunteers to maintain ports, and has the Porter's Handbook as a definitive guide. Yeah, we do have some abandoned ports, and a rather large distcache. Yeah, sometimes a port expires. Yeah, sometimes you can't get something to build on FreeBSD even after trying.

Well, with Red Hat and Fedora messing up the very idea of what's upstream, what's downstream, their spat with OBS Studio is frankly popcorn material to FreeBSD users.

So, after reading this post, what's your take, people?

Oh, another day another drama in Linux. Nothing new ... just one issue - i`m running out of popcorn's.

 

[astyle]

Flatpaks try to solve the packaging problem of having to ship to dozens of Linux distros. They weren't designed with security in mind and may be worse in this aspect for at least 2 reasons:
1. They require kernel features like unprivileged user namespaces that have had security issues in the past. Now web browsers require it so we gotta live with it anyway.
2. Flatpaks aren't updated that often and lots of flatpaks in Flathub are unofficial.

I prefer distro packages when available because they at least have some security scrutiny.

For some large GUI applications Flatpaks make sense. I use containers a lot for other stuff.

I don't get why Ubuntu tries to push Snaps when everybody ships .deb packages for their distro. Flatpaks benefit mostly distros will less users.

OK, let's stick to the topic here... This conversation was less about the benefits of specific packaging technologies and more about policy that governs software storage and distribution. Specifically, conflict resolution.

I was hoping this will not turn into a kitchen sink type of conversation that goes off on any remotely relevant tangent.

Yeah, flatpaks/appimage/whatever have their drawbacks in how they are designed and installed, and how access to repos is managed.

My take is that yeah, Red Hat / Fedora packager should have been more professional in resolving the problem, and should have worked to resolve any technical glitches that arose in the process of packaging. If resolving those glitches was more than the packager had the brains to handle - that's fine, that's why the whole thing is Open Source.

 

[cracauer@]

My take is that yeah, Red Hat / Fedora packager should have been more professional in resolving the problem, and should have worked to resolve any technical glitches that arose in the process of packaging. If resolving those glitches was more than the packager had the brains to handle - that's fine, that's why the whole thing is Open Source.

Exactly.

And there would have been source for a perfectly fine flatpack right there since the original authors made one.

 

[astyle]

Digging a bit deeper into contents of actual messages and conversations the devs had, I'm discovering that it may have been a case of not wanting to spend time testing a package against newer dependencies:

FreeBSD does run into similar issues with pre-compiled packages when shared libs get a version bump that breaks a package. Well, one reason why I prefer to compile from ports!

I do see noise on Forums about latest vs quarterly packages, how some are broken, some are not...

But now I'm beginning to think that my conclusion about lack of professionalism for the packager may have been premature.

Careless comments were made all around, and they did poison the whole conversation. Looking at that ticket now, even OBS Studio devs are walking back their commentary and owning it.

This very well may have been 'storm in a teacup'... But the extreme swings taken (like commentary about complete and immediate removal of OBS Studio from RH/Fedora official repos, completely disabling Fedora's official Flatpak repo, and the like) - that has me shaking my head still.

If FreeBSD Forums' debates are arm wrestling, the discussion at Fedora's Gitlab was a bare-knuckle bar brawl in a bar that would be no stranger to shootouts.

 

[GlitchyDot]

Video about this issue and pinned comment from OBS.
Comment from them:

@fenrirthviti​

2 days ago (edited)
Hi, Joel from OBS here, thanks for the coverage! I can confirm that we absolutely did not want to have to resort to this, but did not feel that they were taking the concerns seriously, and when they resorted to calling us "terrible maintainers" we felt they made their position clear. I'd like to also let folks know that Neal Gompa (who opened the request to remove the Flatpak in addition to ours) manages the RPM, and we do not, and have not, ever had any issues with the RPM which is packaged properly.

 

[cy@]

A little bit of history.

FreeBSD, or should I say a derivative of FreeBSD, PCBSD, later known as TrueOS, used a package technology similar to flatpak. I'm not a fan of this packaging technology but I appreciate the problem they're trying to solve. That of dependency hell.

Traditional packaging technologies, i.e. pkg, pkgng, rpm, deb, and the like are tailored after commercial technologies like Sun's (now Oracle's) pkg. These are conceptually similar what we used on the IBM mainframe, SMP/E. Packages had dependencies (prerequisites), and in the case of SMP/E co-requisites. And if some dependency isn't quite right, you're in a hellish mess, difficult to extricate oneself from.

Flatpak, Snap, and PCBSD pbi packages attempted to address this dilemma by including dependencies in the packages themselves. Easier to use, yes. But the wasted disk space and lack of flexability were the most common complaints.

Enter OSTree (in the Red Hat world rpm-ostree).Here we see the concept of the entire O/S packaged as a single unit, where the package database is similar to a git repository. Again, this trades flexability for ease of use, and especially for the developer, simplifies development because one size fits all.

It's people trying to solve the package dependency cunundrum. Regardless of the method used there are advantages and disadvantages. It's a matter of finding the best solution to your unique set of problems.

Personally: I prefer the traditional packaging approach. Probably because I've used it my whole life.

 

[kpedersen]

Why do you despise Flatpaks?
I have read that each flatpak is isolated from the host running in a sandbox.
Is a flatpak in general not more secure compared to a "normal" package build for one OS?

I suppose it is a similar reason as why we don't run *all* of our software in virtual machines.
Interop and usability greatly suffers.

 

[noise]

Given the pros and cons of Flatpaks, there's definitely some niches where it makes sense, technically. But I see some risks involved on the cultural side, if it becomes the dominant way to distribute packages. Most problems we stumble upon while packaging software are flaws in the build system or the handling of dependencies. Incompatibilities between minor library versions, missing dependencies and build flags or platform-specific code. From a software quality POV we want these to be fixed.

Now remember that as an ecosystem, we're all on a learning journey together. Bundling only that one tested library version will make people more lazy, in regard of these general quality issues. As an example of where this cultural shift could lead, have a look at package systems where version pinning is common, like pip or cargo.

 

[whodat]

So, after reading this post, what's your take, people?

To me it seemed an amicable solution was clear and was asked for by OBS in the beginning: Make sure to clarify to users that this is a third party application and make sure to clarify to the users their options so they may choose to use an official, working application. It seems a reasonable suggestion to me and I have the habit of ceding to reasonable suggestions, no matter how galled I may personally feel to have had someone just publicly call me out for some failing or another.

But I do understand both sides are probably equally passionate about what they do, and sometimes that is hard to express in a pleasant manner, especially with the stress of publicity mixed in.

 

[RokeJulianLockhart]

I don't get why Ubuntu tries to push Snaps when everybody ships .deb packages for their distro. Flatpaks benefit mostly distros will less users.

rbranco, it gives them further reach, since they control what people outside of Ubuntu use, then. Canonical has a tendency to make foremost political decisions that they retroactively justify with dubious technical merit.

 

[Espionage724]

I'm discovering that it may have been a case of not wanting to spend time testing a package against newer dependencies:

If that's the case, Fedora may as well be a rolling-release distro without the testing

I didn't read too-far into the dev discussion, but heard the general idea that dependencies were updated without testing. I thought Flatpak's whole ordeal was to have apps not depend on updating dependencies outside the app dev's control for easier cross-distro packaging.

I'm not sure if it was OBS Studio's Flatpak specifically that was chosen to get updated dependencies (in which case why wouldn't it be tested before shipping?), or if it was a widespread update-everything-in-the-path and OBS just didn't handle it well. But it also feels like there's too-much automation and forward-moving decisions made on a user OS without actual users testing those changes.

It sounds like if OBS's Flatpak change was done in beta, someone would have seen it broken, and not pushed the change. But end-users end up the beta testers?

 

[RokeJulianLockhart]

I didn't read too-far into the dev discussion, but heard the general idea that dependencies were updated without testing. I thought Flatpak's whole ordeal was to have apps not depend on updating dependencies outside the app dev's control for easier cross-distro packaging.

Espionage724, from my understanding, you're describing something more akin to Canonical's Snap, than Flatpak, which is more similar to Steam's runtime.

There is a common userland, under which all manners of hacky changes are performed to standardise that userland for incredibly different OSes (achieved with OSTree). However, that and the increased security provided by the included sandbox render maintaining compatibility with old runtimes difficult.

Considering that repositories are expected to mark dependent runtimes as EOL when they are replaced, I don't believe that your assumption is accurate. Flatpak more exists to provide a common base than negate the need to manage dependencies whatsoever.

It sounds like if OBS's Flatpak change was done in beta, someone would have seen it broken, and not pushed the change. But end-users end up the beta testers?

Unfortunately, Fedora's Flatpak repository doesn't appear to provide a beta branch, like Flathub does. I can't be bothered to go through the rigmarole of ascertaining whether to suggest it at Pagure, GitHub, GitLab, or RedHat Bugzilla. Fedora rather needs to get their act together when it comes to issue tracking. No wonder OBS' maintainers found reporting the bug painful.

 

[astyle]

Considering that repositories are expected to mark dependent runtimes as EOL when they are replaced,

My understanding is that this is actually not the case, as in, it's difficult to know what a library is a dependency of. One basic lib very well could be so popular, that it's a dependency of more upstream projects than you can imagine. This is a good example of where one does need to have a good handle on Directed Acyclic Graph theory and understand the direction of dependencies.

The conclusion of a Best Practice: I'd think that Linux distros do have a responsibility to announce it when they do update basic libs. And they generally do make those announcements - in the release notes and errata. For upstream projects, I'd think that a Best Practice is to make sure the project compiles against the most recent available stuff.

Fedora rather needs to get their act together when it comes to issue tracking. No wonder OBS' maintainers found reporting the bug painful.

Yeah, well, this is Open Source. Everybody relies on what's essentially 'free-of-charge' services. Even FreeBSD. Even Fedora (which is separate from RedHat, and is supposedly upstream, while RedHat wants to call it downstream, of all things! ). It is all volunteer-run. I do agree that it would help to not have so many places to report bugs. Yeah, there are gaps in the production pipeline that need to be plugged. Not everybody is on the same page about whose job it is to make sure that the software is packaged correctly. Unfortunately, there's not much of an enforcement mechanism beyond open market forces.

I mean, even with the FreeBSD project, some packages don't have maintainers, and the Porter's Handbook is THE definitive and authoritative documentation to follow if you want a port to be accepted into the Ports Collection. Porter's Handbook is an effort to follow. But if you do, you'll discover that even then, there's still gaps in the app pipeline and ports that don't work properly. And this is one of the best situations, with a lot of discipline and structure that is really critical for a project to be functional. Compared to that, the situation in the Linux camp is really Wild West, with every project wanting to do things differently.

I mean, even with this, I personally find it rather time-consuming to properly work with the FreeBSD system and do the reporting. But yeah, I do agree that somebody does need to get their act together and do the testing, and get that hole plugged, it really should not be left alone. Just some civility in resolving that is usually appreciated.

 

[SKull]

It's just a Fedora person breaking a piece of software when an unbroken version of the same software is available.

I don't blame the guy.
Building RPMs is tedious to say the least. RPM's documentation is abysmal. And to see what RPM macros you have at your disposal you basically grep, guess and try to extrapolate.
Oh and heaven help if you have a GNU automake project to package.

 

[patmaddox]

Dependencies are hard. A common model in the Linux world is "bundle all the dependencies to simplify things." Others have pointed out that static dependencies result in bigger binaries... but I think that's a fairly superficial problem (other than in very disk space constrained environments).

The main one is that developers ship old dependencies. A library gets updated, and now all of these static packaging formats need to be rebuilt to include the new static dependencies. But developers don't usually care about that - they only care to ship new versions of their own code. Disciplined developers at least update the dependencies as part of their development process. A lot more don't.

A much less obvious and more insidious manifestation of this to me is that library ecosystems diverge and depend on incompatible versions of libraries. It's really frustrating when you've been working on a project for a while, things are going pretty smoothly, and then you add a library to the mix that depends on v0.1 of some other library, when you already have a requirement on v1.0 in the dependency tree. You've got a few options... loosen the version requirements and hope for the best; update the dependency and try to upstream it; maintain your own fork; abandon one of the libraries.

This is just the reality and there's no escaping it. Some approaches make the cost pretty apparent and frankly somewhat painful. Other approaches sweep it under the rug and say look at how easy things are.

I think when we make it really easy to ship any version of any dependency, we also avoid cooperation and communication within the developer community, and that leads to its own issues.

The more I do this, the more I prefer being closer to the root of the problem and dealing with the pain there. It's tempting to add layers of abstraction, and everything seems like smooth sailing for a while... but as soon as something goes wrong, it's layers and layers of crap to try to unravel. Then someone comes along and adds another layer to solve the top-most visible problem.

 

[Alexander88207]

FreeBSD does run into similar issues with pre-compiled packages when shared libs get a version bump that breaks a package. Well, one reason why I prefer to compile from ports!

Usually the PORTREVISION of the consumer ports is raised so that this does not happen on the next run.

It is quite human that this is sometimes forgotten or got bumped a little too late.

For important things like Mesa it is even written in the makefile to prevent it in any case.

But you can also make yourself useful and report this or even submit in a bump.

 

[ShelLuser]

So, I'm late to the discussion but... first of all I'm missing the outcome of all this, IMO an important update (yah, I read the thread). The issue has been resolved after only a few days:

OBS Studio and Fedora resolve Flatpak conflict

The dispute between OBS Studio and Fedora over an unofficial Flatpak package has caused confusion among users. Find out the ...

blog.desdelinux.net

... but second of all it also became obvious that this was only but one out of many issues with those "flatpacks". Also quite an interesting detail I think.

What has me shaking my head is the sheer pettiness I'm seeing in Linux camp... What I say next will only make sense to someone who actually read the Phoronix article I linked to.

Same here, though it also doesn't surprise me one bit. Linux doesn't have a philosophy, a set out goal. The way I see it's often more of an idiology at this time to many people ("you have to believe in it!") and it should also not be too big of a surprise that many people adopt Linux out of spite against others, IMO that also doesn't help.

But because of that it's also often lacking major functionality design in many places. For example: it's called "open source" but actually building your own stuff can often turn into a sheer nightmare: trying to maintain your own build of a software package is majorly different on RPM or DPKG -based distributions, where I think Debian takes the cake because the process is fully integrated. Yet it can still be quite a pain.

... and then we have FreeBSD. Even though it's not generally advisable it is quite easy to utilize binary packages and only build some of these yourself, and can also be quite safe if you know what you're doing.

Note: I'm not saying that either one is better; the way I see it all designs have their own issues to deal with.

Well, with Red Hat and Fedora messing up the very idea of what's upstream, what's downstream, their spat with OBS Studio is frankly popcorn material to FreeBSD users.

So, after reading this post, what's your take, people?

When I read posts like these it always reminds me about the sheer hypocrisy that's often a major part of the Linux community. And I can't help but grin.

You see... it's my experience that many devoted Linux users adopted Linux because "it's not Windows" and of course because "open source" is "obviously" much better than all that "commercial stuff / crap". Who cares that several major examples often clearly prove otherwise? (my personal pet peeve is Pure Data and Max/MSP; both products originated from the same source code where one "camp" went open source while the other started their own company... IMO the major difference in results speak for themselves.. and don't get me started on Office, lol).

But the one thing that always gets me is that many Linux users seem completely obvlivious of the fact that distributions like RedHat, Fedora & Ubuntu are backed by major commercial enterprises themselves. Ones that can be just as stubborn and arrogant as Microsoft often is (let alone dumb & ruthless at times). Yet because it's now about "open source" all of that is suddenly "different"?

It's that sheer hypocrisy why I stopped bothering with Linux politics at all, eventually I also stopped bothering with Linux but that was more because of design and technical issues ("leave FreeBSD alone for 5 years and you'll pick up right where you left off, try the same with Linux and you're probably treated to the "Windows experience" (aka: many changes for no obvious reasons which will only confuse you at first)).

Fun read, thanks for sharing!

 

[blackhole]

This isn't really about flatpaks, snaps or similar. It's about what cracauer@ referred to earlier in thread: i.e. downstream broke upstream's software. That could have occurred in any packaging format, in FreeBSD ports, etc.

The big question here, is largely a political one: Do upstream have the right to demand that their software is packaged in a functional state by downstream, according to their exacting requirements or "remove our name/trademarks or it's $LAWYERS". Many will think they do, many will think otherwise.

For example: Mozilla Firefox. Configure, compile and release it their way or remove the branding. If not? Face the lawyers. Nothing new really.

 

[astyle]

This isn't really about flatpaks, snaps or similar. It's about what cracauer@ referred to earlier in thread: i.e. downstream broke upstream's software. That could have occurred in any packaging format, in FreeBSD ports, etc.

The big question here, is largely a political one: Do upstream have the right to demand that their software is packaged in a functional state by downstream, according to their exacting requirements or "remove our name/trademarks or it's $LAWYERS". Many will think they do, many will think otherwise.

For example: Mozilla Firefox. Configure, compile and release it their way or remove the branding. If not? Face the lawyers. Nothing new really.

I think it's not about the 'right to demand', but more about 'Who is gonna put in the effort to make sure the software works with Fedora/Suse/BSD/whatever.'. Porting and QA is a lot of effort, so who's gonna do it? the distro (who controls the repos) or the upstream project (the one with an interesting product) ?

If neither side wants to put in the effort it takes to make OBS Studio work on Fedora, they can't do much about that until a 3rd party steps in and puts in that effort. It's Open Source after all. Well, both sides know that if there's no effort to make OBS Studio work on Fedora, that weakens Fedora's position as a viable Linux distro. It also weakens OBS Studio if they were to lose their relationship with Fedora. Same can be said of Firefox, LibreOffice, and a lot of other software projects.

As an example closer to home, FreeBSD does have the Ports infrastructure and Porter's Handbook. To be included in the Ports Collection, all you have to do is follow the Porter's Handbook, resolve the technical glitches, and you'll be fine. FreeBSD project does have a dedicated team for porting KDE, BTW. A lot of Linux distros do, as well. Yeah, KDE is developed primarily on Linux, but it's the job of the disrro/BSD to make sure that KDE is functional on the distro/BSD. FreeBSD does have a volunteer maintaining the OBS Studio port. And that volunteer maintainer is expected to work with upstream and resolve technical glitches (instead of bluffing about lawyers and biting when dependency hell breaks things).

Besides, lawyers only get involved when there's sufficient money involved in the dispute, like Java.

 

[GlitchyDot]

For example: Mozilla Firefox. Configure, compile and release it their way or remove the branding. If not? Face the lawyers. Nothing new really.

Well, Mozilla Firefox on Apple stuff is just Safari re-branded.