Flatpak politics getting out of hand?

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.
 
Phishfry said:
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.
Click to expand...

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.
 
astyle said:
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 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?
Click to expand...
Oh, another day another drama in Linux. Nothing new ... just one issue - i`m running out of popcorn's.
 
rbranco said:
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.
Click to expand...
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.
 
astyle said:
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.
Click to expand...

Exactly.

And there would have been source for a perfectly fine flatpack right there since the original authors made one.
 
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:
1739659355761.png


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.
 
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.
 
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.
 
LillieNB said:
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?
Click to expand...
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.
 
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.
 
astyle said:
So, after reading this post, what's your take, people?
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top