Fedora packages versus upstream Flatpaks
The Flatpak package format promises to
bring "the future of apps on Linux
", but a Linux distribution like
Fedora already provides packages in its native format—and built
to its specifications. Flatpaks that come from upstream projects may or
may not follow the packaging guidelines, philosophy, and practices so they
exist in their own world, separate from the packages that come directly
from Fedora. But those worlds have
collided to a certain extent over the
past year to two. Recently, a
packager announced their plans to stop packaging the Bottles tool, used for running
Windows programs in Wine-based containers on Linux, in favor of
recommending that Fedora users install the upstream Flatpak.
Fedora packager "Sandro" posted
about their intent to stop packaging Bottles, starting with Fedora 38,
on the devel mailing list.
Also, the existing packages for Fedora 36 and 37 would not receive any
updates unless there were any security fixes required. The reasons for
doing so are twofold; first, the project "is moving fast and we have been
struggling to keep
up with upstream releases
". That effort has been complicated by the
introduction of some
Rust-based dependencies, which is a problem that Fedora as a whole has also
been struggling with.
In addition, though, an upstream developer approached
the Fedora Bottles team with a request not to package the tool.
A bit more discussion around the upstream effort to persuade distributions to drop Bottles packages can be seen in a GitHub issue for Bottles. The Bottles developers also note that the project is fast-moving, and that the issue tracker only accepts bug reports for the official Flatpak version, both of which make it unfit for distribution packaging in their eyes. In early January, "orowith2os" sent an email to the Fedora Bottles packagers requesting that they drop the package, which got the ball rolling.
The reaction to Sandro's post was less than entirely positive, perhaps
unsurprisingly. Vit Ondruch said
that "the push towards (upstream) Flatpaks is unfortunate
". Pete
Walter agreed and
suggested that the package be assigned to him rather than retiring it.
While "Vascom" thought
that it was a "bad practice to drop packages by upstream request
".
Upstream Flatpaks
Josh Boyer wondered
why Ondruch was opposed to Flatpaks. The problem, Ondruch replied,
is that he does not trust that upstream Flatpaks "follow any standard
except standard of their authors
". Beyond that, Flatpaks do not really
live up to their billing:
And I don't like [Flatpaks], because their main advantage (their isolation) is also their biggest disadvantage. There can't be both without making compromises. If I am not mistaken, the isolation is also mostly myth, because it is disabled in most cases.
There are a few questions that come to mind for upstream Flatpaks, according to
Richard W.M. Jones: "How do we know they don't contain non-free
software? How do we ensure we can obtain and rebuild from source?
"
The answer to those questions is that "you have to trust that the
maintainer of the upstream F/OSS
project cares about and ensures those things
", Adam Williamson said.
However, he has experienced upstreams that have a different interpretation
of "F/OSS" from his or Fedora's, so that path can be problematic.
Kevin Kofler complained that a package should not be allowed to simply be retired, it should first be orphaned, which gives an opportunity for others to package and maintain it going forward. But the idea of moving toward upstream binaries instead of Fedora packages is not a good one, he said:
IMHO, retiring a Fedora package in favor of an upstream binary of whatever kind (Flatpak, Snap, AppImage, RPM, binary tarball, whatever) is a major disservice to Fedora users and defeats the whole point of having a distribution to begin with.
But Patrick Griffis was concerned
that orphaning the package would just lead to an outdated package that will
degrade over time. "I think it is far more responsible, and
respectful of users, to accept that some packages are better maintained
elsewhere.
" Michael Catanzaro pointed out
that an orphaned package will be automatically retired after a few weeks if
no one takes it over; if someone does take it over, they will hopefully be
able to maintain it well:
If the only problem with the package is the current Fedora maintainer isn't able to keep up with updates, as seems to be the case here, then orphaning gives a chance for somebody else to try to do better. Hopefully a new maintainer will only take the package if confident that they can keep it updated.
Flathub
The main source of Flatpaks that can be installed on any Linux distribution
is Flathub, but it will probably
come as no surprise that opinions vary on its quality. Jiri Eischmann said
that he maintains packages for Fedora as well as Flatpaks for Flathub and
has found that the "review to get an app to Flathub was as thorough as Fedora
package review
"; in fact, it was sometimes more strict. But Neal Gompa
noted
that some Flatpaks, notably Firefox and OBS Studio, do not have to follow those
rules. Robert Marcano pointed
out that many Flatpaks on Flathub are just built from binaries built by
other projects.
Eischmann acknowledged that Flathub allows exceptions, including allowing Mozilla to simply upload its Flatpaks directly to Flathub; he still sees value in the repository, though:
But Flathub is still a curated repo. If you want to deviate from standards you have to justify it, if you're doing something fishy your flatpak may be taken out. But [ultimately] you have to trust the author, but that applies to Fedora, too, just to lesser [extent].
The Firefox example is an interesting one, Williamson said, "because it's *exactly* a
case where I trust the Fedora builds more than I trust upstream's
".
Mozilla has made some "sub-optimal choices in search of revenue
", in
his opinion, so he would prefer to get his Firefox from Fedora, which is
not faced with the same quandary. Gompa noted
that there are other differences in the Mozilla builds, like disabling
address-space layout randomization (ASLR). "It's actually hard to figure
out what upstreams
are doing with their own builds, and sometimes they intentionally make
it harder to figure it out.
"
Sandro was clearly surprised by the number of responses they received. It turns out that Sandro had only recently adopted Bottles after its last orphaning; they are not unwilling to turn it over to Walter but want to discuss it with the co-maintainers first. There is an open pull request to update Bottles to a version from October 2022, but since that time six more upstream releases have been made.
Part of the problem in keeping up with the Bottles upstream is its dependency
on the Python orjson JSON
library, which in turn depends on being able to build the Rust code inside
it. "Maxwell G" said that he
made a start on packaging orjson for Fedora but could not commit to
maintaining the package; Ben Beasley volunteered
to help. Fabio Valentini pointed
out that if orjson had already been packaged for Fedora, the problem
for Bottles
would not have reared its head at all: "you'd probably not even notice
that one of the many Python
packages with 'native' modules in Bottles' dependency tree is actually
implemented in Rust and not in C. :)
"
It would seem that Sandro plans to bow out, but that others are likely to
step up, so Bottles should have a future as a Fedora RPM. That does not
resolve the disagreement with the Bottles upstream, however. As Maxwell G
put it, though, the request to drop the RPM "feels inappropriate and
somewhat antithetical to the tenets of OSS
". For Bottles, at least, the
situation seems more or less resolved at this point, with the upstream
request being turned down. But this is not the last we will hear of the
conflicts between Flatpaks and distribution-specific packages, especially
now that unfiltered
access to Flathub will be available in
Fedora 38.
Posted Feb 7, 2023 21:54 UTC (Tue)
by mb (subscriber, #50428)
[Link] (11 responses)
a) packages that are not yet packaged by distributions.
or
b) packages that need to change so frequently due to external factors that distributions can't keep up. e.g. browsers.
Rust dependencies are not a reason for having flatpak, though.
Posted Feb 7, 2023 23:10 UTC (Tue)
by koh (subscriber, #101482)
[Link] (7 responses)
> keep up with. e.g. browsers?
Posted Feb 7, 2023 23:23 UTC (Tue)
by ibukanov (subscriber, #3942)
[Link] (5 responses)
Posted Feb 8, 2023 8:29 UTC (Wed)
by taladar (subscriber, #68407)
[Link] (2 responses)
Posted Feb 16, 2023 16:23 UTC (Thu)
by mrugiero (guest, #153040)
[Link] (1 responses)
Posted Feb 16, 2023 17:30 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
The build mechanisms may also vastly differ. From my time with WebKit building, there is a *lot* of generated code (which I assume Chrome still has). I have no idea how much codegen Firefox does though.
[1] https://ftp.mozilla.org/pub/firefox/releases/110.0/source/
Posted Feb 8, 2023 18:06 UTC (Wed)
by koh (subscriber, #101482)
[Link] (1 responses)
The risk you mention exists as of time T0 where event 0. happened until T7. You appear to refer the time T5 to T6 as a critical delay, though as a simplification building the software by distributions (5.) takes exactly as long as a single test in point 3. Potentially also point 2. depending on whether the developer uses incremental builds for it or not. T6 can be seen as instantaneous. I would argue that neither T3 nor T5 are of significance here. It's rather T0, T1 and T2 that influence risk most heavily.
Posted Feb 8, 2023 18:15 UTC (Wed)
by pizza (subscriber, #46)
[Link]
This definitely isn't true; there's typically some internal distro process that delays things (eg promoting from updates-testing to updates).
At the same time, even when getting the binaries straight from the browser maker via their automated update mechanism, the updates aren't pushed to everyone simultaneously either; there's typically a staged release.
Even then the delay between the packages/binaries being available to when they're actually applied (whether the binary comes from the distro or the browser vendor directly) usually requires the user to acquiesce to having the browser restarted, and IME is typically the longest pole in practice.
Posted Feb 9, 2023 22:35 UTC (Thu)
by plugwash (subscriber, #29694)
[Link]
The problem with the two main web browsers chromium and firefox is:
1. Chromium doesn't produce lts releases at all and while firefox does, those lts releases still have quite short lifecycles compared to what the linux distros need.
The result is that linux distros are practically forced to update to new major versionsnof browsers even in stable releases.
My understaning is that packaging new versions of browsers for old versions of Linuc has vecome increasingly difficult due to various dependencies. Ubuntu recently threw in the towel and created transitional packages that install the snaps instead. Debian is still trying and seems to be doing an ok job with firefox esr but chromium in Debian has gone unmaintained for significant periods in the recent past.
Posted Feb 8, 2023 0:14 UTC (Wed)
by flussence (guest, #85566)
[Link] (2 responses)
ncdu is a good example, it was useful and then it was rewritten in Zig, which means anyone on a source-based distro wishing to use it now has to suffer an entire bundled copy of LLVM for one CLI program. Gentoo offers a precompiled binary version as a mercy, but it would probably be better if they could just redistribute a self-contained version in one of these formats.
Posted Feb 8, 2023 6:50 UTC (Wed)
by WolfWings (subscriber, #56790)
[Link]
Yes, I know there's 'bin' packages for most of it but that's another whole jumble of complexity versus just surrendering on the source-based front since I'm more busy using than developing software these days.
Posted Feb 8, 2023 21:40 UTC (Wed)
by jond (subscriber, #37669)
[Link]
Posted Feb 8, 2023 5:29 UTC (Wed)
by jhoblitt (subscriber, #77733)
[Link] (24 responses)
Development norms have changed, CI/CD systems that crank out binaries on demand (or even every commit) are now ubiquitous. Fetching actively moving software directly from upstream is now common place be it an OCI image, appimage, yum repo, or flatpak -- I use all of the above daily.
I am surprised by the attitude that some end users trust an upstream to write software but not compile or package it. If an upstream cant be trusted to operate the build system they wrote... It's time to find a different upstream.
Posted Feb 8, 2023 6:16 UTC (Wed)
by PengZheng (subscriber, #108006)
[Link]
Posted Feb 8, 2023 7:42 UTC (Wed)
by Conan_Kudo (subscriber, #103240)
[Link] (4 responses)
Posted Feb 8, 2023 10:07 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (3 responses)
The question becomes whether or not the contribution is valuable, or just duplication of effort. A distro packager who expects to only be responsible for the builds in their distro of choice, and nothing more, is just duplicating effort; there's no added value from having something built as a Fedora RPM as well as a Debian dpkg and a CentOS RPM.
A distro packager who does things like testing against newer library versions and reporting back to upstream that it's possible to move from libfoo-1.1.1 to libfoo-1.8.6 safely is valuable. As is a distro packager who handles front line support, from recommending tutorials to people who've installed the program and now want to be told how to use it, all the way through to producing good bug reports from user reports of the form "I installed it and it doesn't work".
Posted Feb 15, 2023 15:03 UTC (Wed)
by immibis (subscriber, #105511)
[Link] (2 responses)
Maybe one day effort will be merged into a distribution-development-kit based on bitbake or portage. Then Fedora can be DDK with one set of custom packages (e.g. branding) and compile options, and Ubuntu can be a different one.
The package manager itself is a relatively small amount of work compared to the work required to actually make the packages.
Posted Feb 15, 2023 17:24 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
> Maybe one day effort will be merged into a distribution-development-kit based on bitbake or portage. Then Fedora can be DDK with one set of custom packages (e.g. branding) and compile options, and Ubuntu can be a different one.
Well, portage is a damn good system for building a distro. Throw in systemd as the one init system to rule them all :-)
But I think where systemd and portage both (like a huge amount of Open Source software) fall down badly is the lack of decent STARTER documentation. Open Source documentation is good, but it's mostly of the sort that only makes sense once you already know what it means - it's a reference not a tutorial. I've written my own systemd init file and it was torture, because I didn't know where to start. And I still think it's got a number of nasty glitches that I need to debug. However I really don't think SystemV would have been any easier ...
Cheers,
Posted Feb 20, 2023 12:58 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
But those opinions are of very little value if the packager isn't communicating the results of complying with those opinions upstream. If a distro packager is building for X11 only, and upstream removes all X11 support (making their package Wayland-only), then the distro's opinion stops having any weight, since it becomes "remove package" versus "stop holding the opinion that X11 is required".
To be of value beyond simply providing a nice way to do ./configure && make install, packagers need to be communicating with upstream, and ensuring that the reasons behind distro opinions are respected upstream (which is hard work in its own right - the packager job is not simple or easy). If they're not, then distro packagers are going to duplicate each other's work, and upstream is not even going to realise that distro packagers have opinions that differ from theirs, nor why.
This becomes problematic if upstream's decision making results in them dropping code distributions need to implement their opinions - if you remove X11 support code because you think that everyone's using Wayland now, but my distribution package patches out Wayland support and only builds the X11 version, then we get an unpleasant collision. Had I been telling you why my package patches out Wayland support, you'd almost certainly have kept X11 support, or worked with me to fix the reasons why I patched out Wayland.
Posted Feb 8, 2023 10:19 UTC (Wed)
by LtWorf (subscriber, #124958)
[Link]
The problem is that more often than not they also download binaries.
In the end you end up with a binary and no clear idea on what the license is and where the source code is.
You basically invented windows.
Posted Feb 8, 2023 11:07 UTC (Wed)
by paulj (subscriber, #341)
[Link] (4 responses)
Then in the Linux world there is the issue that there are many many different kinds of systems, and a plethora of deployment options. Upstreams just can't keep up.
Posted Feb 8, 2023 14:26 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (3 responses)
And there's a "holy grail" being chased here - can we divert the people who build maintainable systems into doing it upstream, as opposed to integrating pieces downstream?
To choose a random example, if you install the Linux kernel from the Debian archives, you get a version with over 100 patches applied atop the upstream release. Some of those are specific to Debian policy, and thus fair enough, but others are about making the kernel a better part of a maintainable system; those patches should be upstream. For example, there's 6 patches to firmware loading; one is fair enough as a downstream patch (it changes the kernel to point to Debian documentation on firmware), but the other 5 are meant to be improvements to firmware loading. There's another two that set kernel taint if you use known-buggy features - this is something that probably belongs upstream, too (albeit maybe not in the form that Debian has it).
That's at least 7 of the hundred-odd patches Debian carries to a single piece of software that are relevant to building the software into a maintainable system rather than to Debian-specific changes, and that therefore would be beneficial to have upstream, helping everyone trying to use the Linux kernel as a component in a maintainable system, as opposed to downstream, only benefiting people trying to use Debian as a component in a maintainable system.
Posted Feb 8, 2023 14:53 UTC (Wed)
by paulj (subscriber, #341)
[Link] (2 responses)
Unless you mean retain the 'system' communities of distros, and encourage them to upstream more work. That I would agree with. Having been an upstream, it was actually frustrating how /little/ the distro package maintainers would communicate with upstream and how rarely they tried to upstream their changes and ancillary packaging work.
Posted Feb 8, 2023 15:33 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (1 responses)
I do mean the second paragraph; yes, there are changes that distros make that are distro-specific - no upstream wants a patch that links to Fedora-specific documentation, for example - but having the work needed to make a given piece of software part of a maintainable system living in N different distro patchsets along with distro-specific changes is duplication.
And that duplication becomes waste when you get two people who would happily improve each other's implementations of a change instead working from scratch because neither of them has submitted their version to a shared location, and thus they don't know that there's a collaboration possible.
Posted Feb 10, 2023 6:14 UTC (Fri)
by pabs (subscriber, #43278)
[Link]
Posted Feb 8, 2023 13:54 UTC (Wed)
by jzb (editor, #7867)
[Link] (4 responses)
" I am surprised by the attitude that some end users trust an upstream to write software but not compile or package it. " One of the benefits of using Debian, Fedora, etc. is the oversight they have for licensing, testing, packaging, and everything. If I want to run a program where I've no prior relationship with the upstream or much info about it, using a package from the distro (at least in theory) provides an extra layer of oversight and vetting for the software. I'm not claiming this is a perfect system, but I place a fair amount of trust in the maintainers of various Linux distributions and expect that they will work out a lot of issues before the software gets into my hands. "All of the time spent by literally dozens of Linux/BSD distributions repackaging the same software has a high opportunity cost for the community; that effort could instead be investigated in improving software." Could is doing a lot of work in that sentence. :-) If all the people working on open source *nix OSes could work together instead of redundant efforts and if they'd channel that labor into other things to improve software, usability, security, hardware support, etc., then all the proprietary OSes would be sidelined by now. People being people, though, most of the attempts to join together on these types of efforts have fallen apart or fallen very short. People doing the work as volunteers tend to want to just work on stuff they like doing, and don't want to be told how to do it. The companies willing to pay people to do this work are usually unwilling to go too far in the direction of providing support to competitors. But, yeah, in a perfect or even moderately less imperfect world, everybody could work together and make things better.
Posted Feb 8, 2023 16:07 UTC (Wed)
by southey (guest, #9466)
[Link] (3 responses)
A second important reason is that bugs are found and are quickly reported and solved by the distro maintainers. I am not confident that upstream responds as quickly as distro maintainers appear to do. Also that effort is actually improving the software expecially as the upstream developers typically lack a diverse range of hardware to test on. How many developers have Intel, AMD, ARM, and MIPS systems (Debian 'bulleye' supports nine major architectures)? It is an eye opening experience to test developer code such as release candidates especially when the known tests fail on your system. It is an large amount of effort doing testing but you know that your reports makes the code better.
Posted Feb 8, 2023 19:57 UTC (Wed)
by SLi (subscriber, #53131)
[Link] (2 responses)
Alas, software is not bug-free. If you take a modern browser and replace 159 libraries with slightly random versions of the same or compatible libraries built on your platform, you are virtually certainly going to expose bugs that do not exist in the upstream binary. And no, distributions are very unlikely to be experts in testing such a complex piece of software at a level comparable to the upstream.
Now, I believe it's been the case for a while that even distributions have given halfway up and just accepted, grudgingly, that browsers vendor their own specific versions of all libraries.
I do understand the distro motivation for all this, believe me, with how much easier it is to replace one library with a vulnerability than a thousand copies. But I feel that at the level of software development the world currently is, I think it's madness to expect that you can just throw stuff together from hundreds of sources and expect it to work just as well as the blessed upstream version.
Posted Feb 8, 2023 20:03 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (1 responses)
Posted Feb 9, 2023 10:37 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
And, thanks to distro engineers being humans too, some of those backports will introduce new bugs that aren't present in any upstream version of the library. So even if I've tested and confirmed everything works on library versions 1.21 and 1.22 from upstream, a distribution's version of 1.21-2 with a fix backported from upstream 1.22, but otherwise the same as upstream 1.21 may exhibit the bug.
Posted Feb 8, 2023 16:55 UTC (Wed)
by sionescu (subscriber, #59410)
[Link]
Why surprised ? It seems pretty obvious to me that most upstream developers know close to nothing about integrating a piece of software into the OS. It's very similar to how I've met plenty of good software developers that knew their business matter very well (e.g. in banking, GIS, electronics simulations) but had absolutely no competence in running the code they wrote. That's why the ops team was around.
Posted Feb 8, 2023 20:34 UTC (Wed)
by rgmoore (✭ supporter ✭, #75)
[Link] (1 responses)
The availability of CI/CD systems that can turn out a binary on every commit does not mean it's a good idea to distribute those binaries. Developers need to have access to source because they have to compile things for themselves, but a binary format like flatpack is designed for people who aren't going to do that. If you encourage those end users to get the latest, hot off the CI/CD server version of your software, they'll wind up with a huge number of different versions of wildly varying quality. The variable quality will hurt the project's reputation, and any bug reports they send are going to be nearly useless because of that plethora of versions of variable quality. It might be a bit more effort, but it would be more productive in the long run to produce versions that are actually intended for release rather than development snapshots. It's possible those will still come out faster than distributions want to, or even can, keep up with, but it will still be a far sight better than having users get random stuff from your CI/CD system.
Posted Feb 8, 2023 21:02 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link]
Posted Feb 9, 2023 4:51 UTC (Thu)
by dilinger (subscriber, #2867)
[Link]
For example, I recently updated debian's copyright file for harfbuzz, and in doing so discovered a font that had a license that forbid distribution. I notified upstream, and it is now removed upstream. I can't count the number of times that I've packaged something and discovered no license, or license violations (especially GPL ones where the source code for something isn't supplied), or license conflicts, or ambiguous licensing. The whole many-eyes things only works if there's actually many eyes.
Similarly, in packaging chromium for Debian, I often find issues that upstream doesn't come across because they're focused on ARM on android, rather than desktop linux. Those fixes also go upstream.
And, of course, there's the patches that disable stuff that we don't like about upstream (like supporting 3rd party cookies by default), or that don't fit with the distribution (like things that assume a certain filesystem layout or desktop stack), or that enable hardware that upstream doesn't support (like ppc64 and x86), or just changing the defaults (like switching the search engine from Google to DuckDuckGo). It's not so much about trust, as it is about motivation. Upstreams have their many varied reasons for doing things, and distributors have their reasons. They're often aligned, but sometimes they're not. When they're not aligned, that's when distribution packagers bring a lot of value.
Posted Feb 9, 2023 15:12 UTC (Thu)
by smoogen (subscriber, #97)
[Link]
Those end users are doing that.. they are wanting a third party to do the work in an auditable method. For many of these users, the years of experience of either being an upstream or working with an upstream have taught them some hard truths. It is very rare for an upstream to write their build system from scratch. Most are relying on other people's code to make the build work. They usually didn't compile their own compilers system libraries, or other utilities but are relying on some distribution to do it for them. They are usually not spending too much time on various auxilliary libraries but letting whatever pip, cargo, gems, etc brought in.
If the upstream does its job well, then it will pass along what all those decisions to you the consumer in some form of bill of materials or manifest. In some cases, you will get a blob of software that they compiled, and a bundle of all the libraries, helper-apps, etc that the upstream has felt was needed to make their blob work. Basically every snap, container, flatpak, etc is its own distribution. If you are lucky they may choose to use a layer provided by some other operating system as that basis, but in many cases.. they don't.
That is probably not a big problem.. linux has been about exploding numbers of distributions since its beginning. The bigger issue is that most of the users do not assume problems with said containerized application is the responsibility of the upstream. Instead security problems, XYZ app ate all my files, etc are shoved onto the distribution as it is what the user knows and what gave them the downloader which got the flatpaks or snaps or containers in the first place.
Posted Feb 16, 2023 16:32 UTC (Thu)
by mrugiero (guest, #153040)
[Link] (1 responses)
The issue is not trusting the devs as packagers, but the resource consumption of the solutions they would depend on. Windows had DLL hell. Now we have OS-in-a-tar hell, which is actually worse. For the same reason you can't expect a dev to package for every distribution, you can't expect them to use the same runtime base image to ship it as you currently have installed, and my disk and RAM waste will increase a lot thanks to that. Compare that to shipping only the libraries you actually need.
Posted Feb 17, 2023 12:24 UTC (Fri)
by mrugiero (guest, #153040)
[Link]
s/The/My/
Seeing other comments, I see there are much heavier concerns that I just usually don't take into account. But where I come from, not wasting hardware is of paramount importance, to the point that people use "it's lighter than Windows" as a selling point for Linux. The container-as-an-app world will soon make that false.
Posted Feb 8, 2023 7:04 UTC (Wed)
by vwduder (guest, #58547)
[Link] (1 responses)
But if you're going to do that, make damn sure you take on the front-line of support instead of dumping that on your upstream.
Packaging software for your distribution goes beyond making the bits available. You need to be front-line support for your users too. If you can't commit to that, perhaps don't commit to packaging it.
Posted Feb 8, 2023 7:38 UTC (Wed)
by Conan_Kudo (subscriber, #103240)
[Link]
Posted Feb 8, 2023 8:47 UTC (Wed)
by epa (subscriber, #39769)
[Link] (4 responses)
Surely Flatpak needs the same concept. If you don't want to trust the creator of a binary image -- or indeed, you're not tinfoil-hat paranoid but you just believe that relying on binary blobs, is in the end, unhealthy -- then you could pull down the source Flatpak instead and rebuild it. The job of distributions like Fedora would then be to make sure that the necessary development tools are available so the application can build.
Posted Feb 8, 2023 9:36 UTC (Wed)
by wjt (subscriber, #56250)
[Link] (3 responses)
(Apps using the "extra-data" feature to pull non-redistributable binaries at install time obviously don't have the sources for those.)
Posted Feb 8, 2023 16:16 UTC (Wed)
by IanKelling (subscriber, #89418)
[Link] (2 responses)
But I just searched for google chrome. Clearly the sources are not available for that since it is proprietary. Flathub seems to intentionally disregard software freedom in many ways, including:
* Proprietary javascript on website required to see anything.
> published on its own infrastructure
So does flathub host the binaries for firefox and obs or does it just direct you to some third party server in the background? OBS is GPLv2, so there should be instructions for rebuilding it. Flathub creating headaches for people doing gpl compliance if there is no uniform commands for rebuilding anything.
Posted Feb 8, 2023 23:48 UTC (Wed)
by mebrown (subscriber, #7960)
[Link]
So, no, there is no single file you can download to install the package. There is no single file to download to get the source. You have to have either flatpak or ostree installed to pull the repo.
Posted Feb 9, 2023 17:24 UTC (Thu)
by wjt (subscriber, #56250)
[Link]
My original comment should have been clearer: apps like Chrome are what I was referring to as "extra-data". The .Sources extension still exists but doesn't contain the source to Chrome itself. The former. They are built elsewhere, but hosted and published by Flathub. ("published" was the wrong word in my grandparent comment.
Posted Feb 8, 2023 10:25 UTC (Wed)
by wtarreau (subscriber, #51152)
[Link] (5 responses)
So basically anyone switching to flatpak for this software wouldn't even be able to roll back to the last working version when facing a bug. That looks everything but serious. The last time I saw this being done, it was a company trying to force their users to progressively adopt the paid version of their software by trying hard to get rid of all the free stuff (and they even erased their github history).
I don't know the motivations here but all of this doesn't smell good at all. I never heard about that project before, but the first time I've heard about it just convinced me to stay very far away from it due to particularly user-unfriendly practices.
Posted Feb 8, 2023 10:27 UTC (Wed)
by wtarreau (subscriber, #51152)
[Link] (4 responses)
Posted Feb 8, 2023 14:29 UTC (Wed)
by wjt (subscriber, #56250)
[Link] (3 responses)
Downgrading with Flatpak is documented here. I don't know whether Flathub keeps a certain number of past builds of each app, or past builds until a certain age, but flatpak remote-info --log flathub com.usebottles.bottles shows 6 previous builds, dating back to version 2022.10.14.
Posted Feb 8, 2023 15:22 UTC (Wed)
by wtarreau (subscriber, #51152)
[Link] (2 responses)
Posted Feb 8, 2023 21:57 UTC (Wed)
by dbnichol (subscriber, #39622)
[Link] (1 responses)
However, since what you're committing can be pretty massive, it's pretty typical to prune the repos. At Endless I think we currently have all of our repos setup to prune after a depth of 4 commits and there's a job that prunes them all daily. Our repos are a fraction of the size of flathub's, too.
One thing that's lacking in ostree relative to git is tags. At Endless when we make releases I made up a custom to create a ref under release/ pointing to the released commit. A fake tag if you will. Then you can always pull release/os/eos/amd64/4.0.13 or whatever. That works well for our OS, but there we're a lot more disciplined with version numbers. When we used to do more Flatpak apps, people did not want to make up release version numbers. They just wanted to pump out the next update.
Flathub is similar. There is a version number shown, but it's optional and it's the usually the upstream version recorded in the commit. There aren't any tagged commits.
Posted Feb 10, 2023 6:11 UTC (Fri)
by pabs (subscriber, #43278)
[Link]
Posted Feb 8, 2023 10:59 UTC (Wed)
by pauldoo (subscriber, #124140)
[Link] (1 responses)
Posted Feb 8, 2023 22:22 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link]
Don't see this as viable. Fedora flatpaks are sourced from OCI (docker) containers stored in Fedora registry which in turn are built from Fedora RPMS. Flathub shares none of this mechanism. They just produce results in the same format.
Posted Feb 11, 2023 8:57 UTC (Sat)
by cyperpunks (subscriber, #39406)
[Link]
Posted Feb 11, 2023 21:39 UTC (Sat)
by nedrichards (subscriber, #23295)
[Link]
Fedora packages versus upstream Flatpaks
That's just because distributions have not adjusted their packaging systems to how Rust works, yet.
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
[2] https://github.com/zcbenz/chromium-source-tarball/release...
Fedora packages versus upstream Flatpaks
0. vulnerability is found and exploitable
1. disclosure of a vulnerability to the respective browser development team
2. implementation of a fix for it
3. testing the implementation and verifying that it actually solves the problem
4. release of new browser version
5. distributions start building new browser version
6. distributions send out new packages
7. users install distributions' updates
Fedora packages versus upstream Flatpaks
> T6 can be seen as instantaneous.
Fedora packages versus upstream Flatpaks
2. They attract security issues at a rate that means distros consider doing their own secirity patch backports impractical.
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Not really. What happens instead is that those people don't contribute to anything. The opportunity cost is having them contribute to the ecosystem at all. Most packagers are not programmers at the level of the developers making the software, at least not in the beginning. They sometimes learn along the way, though.
Fedora packages versus upstream Flatpaks
It's interesting how often people make the mistake of thinking that people working in distributions to package software would redirect their effort to Flathub or upstream developers if the option was missing in the distribution...
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Wol
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Development norms have changed, CI/CD systems that crank out binaries on demand (or even every commit) are now ubiquitous. Fetching actively moving software directly from upstream is now common place be it an OCI image, appimage, yum repo, or flatpak -- I use all of the above daily.
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
So, the hypothetical choice is between opportunity cost in the distro vs actual material cost in the users' computers. I'll take the first one every day of the week, but we all have our own opinions.
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Distributions that aren't taking frontline support are doing it wrong. As a packager in a distribution, my expectation is that people come to the distribution first for their issues, and then we figure out if it's something to bug upstream about. The only exception is when the upstream wants the distribution issues reported to them directly (like KDE does, for example) and accommodates identifying distribution sources when filing bugs.
Fedora packages versus upstream Flatpaks
Source packages?
Source packages?
Source packages?
* Can't filter out proprietary apps on the website.
* I can easily download source packages from debian with a web browser. The flathub website says I need to install flatpack, yet it only gives a list of distros for doing it and my distro, Trisquel is not on the list. I tried appending .Sources to a flatpack download link and I got 404.
* What about building the sources? Last time I looked into this about this like a year ago, I ended up filing a bug and my vague memory of the response was "getting & building sources is mostly undocumented, and we are redoing our entire docs, maybe we will include it."
Source packages?
Source packages?
But I just searched for google chrome. Clearly the sources are not available for that since it is proprietary.
So does flathub host the binaries for firefox and obs or does it just direct you to some third party server in the background?
Upstream not necessarily better in this case ?
Upstream not necessarily better in this case ?
Upstream not necessarily better in this case ?
Upstream not necessarily better in this case ?
Upstream not necessarily better in this case ?
Upstream not necessarily better in this case ?
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks
Fedora packages versus upstream Flatpaks