7 ms·

This LWN article makes the matter supremely confusing. The linked mailing list post is way better and clearer and it would be good to get this submission change

This LWN article makes the matter supremely confusing. The linked mailing list post is way better and clearer and it would be good to get this submission changed to it: https://lwn.net/ml/fedora-devel/20230601183054.12057.45907@mailman01.iad2.fedoraproject.org/ https://lwn.net/ml/fedora-devel/20230601183054.12057.45907@m... Key excerpts: > … the LibreOffice RPMS have recently been orphaned … > … will contribute some fixes upstream to ensure LibreOffice works better as a Flatpak, which we expect to be the way that most people consume LibreOffice in the long term. > Any community member is of course free to take over maintenance, both for the RPMS in Fedora and the Fedora LibreOffice Flatpak, but be aware that this is a sizable block of packages and dependencies and a significant amount of work to keep up with.

Gigachad 3y ago
This is probably how things will be moving. It doesn't make sense for every single distro to maintain customized versions of user level applications now that we have one package that works everywhere.
- ekianjo 3y ago
  Works everywhere is a stretch. Flatpaked applications have multiple issues
  - qbasic_forever 3y ago
    Bespoke RPMs that have to be patched and modified for distros by a small group of maintainers have issues too.
    - b112 3y ago
      Redhat is just falling. It was a pain doing packages 25 years ago, comparatively it is simple now. Frankly, the flatpak will have issues as well, but those will be outside of Redhat's direct control. Which means the end game, will be a redhat flatpak.
      - worthless-trash 3y ago
        Red Hat will almost definitely work with upstream to "fix the problem". Red Hat engineerings mantra is "Upstream first", the financial cost of maintaining a difference from upstream is a detractor to encourage users from using upstream builds.
- contrarian1234 3y ago
  You're talking about AppImages right? I've tried several times to understand how Flatpak works and how to integrate a CMake build with Flatpak.. and I'm honestly befuddled. Granted a quick Google search does show the situation has improved a bit in the past year. I imagine if you're trying to package a Zig or Clojure application it's going to be a lot of figuring things out on your own
  - Laaas 3y ago
    Flatpak is quite simple under the hood, it's just a wrapper around bubblewrap [0]. I'm not sure what you mean with integrating it with a CMake build. [0]: https://github.com/containers/bubblewrap https://github.com/containers/bubblewrap
  - dale_glass 3y ago
    AppImage is also troublesome. I just spent a good while debugging ours. The TL;DR is that AppImage amounts to a self-extracting archive, and you need an application where all the binaries and libraries have a relative rpath. So rather than loading /usr/lib/libz.so, it uses $BINARY/../lib/libz.so. That part's not too bad, but what can cause a lot of trouble is that there's a fair amount of stuff that uses dlopen at runtime. So you might find that you think you packaged everything, but then the app loads some module from the host system, the API isn't compatible and it explodes in some confusing fashion. So yeah, Linux app distribution is a pain no matter what it seems.
    - duped 3y ago
      Can't you just add an rpath to your main executable (which cmake does by default for release builds that aren't installed, fwiw) or use a launcher that sets LD_LIBRARY_PATH?
      - dale_glass 3y ago
        You can, the trouble is that you don't know that say, libfoo.so loads libbar.so at runtime, and so you need to also package up libbar.so. Otherwise, libbar.so won't be found in your AppImage, will get loaded from the host instead, and now it explodes but only on some distributions. In my case it was OpenSSL loading stuff at runtime.
- creatonez 3y ago
  > It doesn't make sense for every single distro to maintain customized versions of user level applications now that we have one package that works everywhere. It does make sense for at least one distro to be offering this, as there are numerous reasons to favor the traditional linux distro way of doing things. Flatpak is better for a lot of use cases, but it's missing a lot by not having a centralized system of checks and balances provided by a Linux distro. Fedora Flatpak brings back a lot of the advantages of traditional Linux distributions, but unfortunately Fedora/RHEL likely won't be maintaining a Fedora Flatpak version of LibreOffice.
  - Conan_Kudo 3y ago
    New maintainers picked up LibreOffice, so that will still happen, since LibreOffice wasn't retired from Fedora.
    - ladyanita22 3y ago
      Did they? I understand then that users may still get the EPEL libreoffice.
- bandrami 3y ago
  Flatpak is a non-starter for me. The runtimes required by my office would mean 2 KDE versions and 2 Gnome versions installed as flatpak runtimes in addition to the KDE running on the host, which quintuples the security space I need to monitor. Sweeping package management problems under a rug doesn't actually make them go away.
  - dralley 3y ago
    Flatpaks unlike Snaps are actually sandboxed properly.
    - seabass-labrax 3y ago
      Just being sandboxed though isn't a help if you actively want the software to process sensitive data! If you want to read a private document in LibreOffice, you have to be sure your copy of LibreOffice and every library it calls is trustworthy and reasonably secure.
      - yjftsjthsd-h 3y ago
        I dunno, if it's sandboxed and doesn't have network access then the only attacks I can think of are either really indirect (embedding an attack in saved files in hopes of hitting another user) or really targeted (altering a specific document or phrase when it's read). Assuming the sandbox works and includes blocking of network access, what attack do you see a word processor performing even when handed sensitive data?
        bluGill 3y ago
        Most word processors have some web abilities. Click and link and the web browser opens. That link can be custom crafted to send data.
        iudqnolq 3y ago
        Suppose your word processor is allowed to write to arbitrary files in your home directory. It writes a line into your .profile that CURLs your sensitive data to it's server. This has a level of indirection, but that just delays things until the next login. With a little more work there are infinite other places you could inject that might run sooner.
- ho_schi 3y ago
  Because there are pros and cons for each type of packaging but native distro packages and Flatpak will go-exist. It does already on my machine. Distribution packages: + necessary for base system + small memory requirement + small package size + all checked by distro + work well together + on fix, fixes it for all o lot of work for maintainers downstream - bugs hard to figure out for upstream - problematic with closed-source Flatpak: + programmer packages is/her software once and only once + support all distributions i.e. Linux + use selected dependencies + control-groups and namespace are in place for lock-in + autonomous offline package handling e.g. “storeable on thumbdrive” - huge maintenance burden, especially security, on programmer - higher memory usage - big package size Usually if I see something entirely new (e.g. Marker some years ago) or something using Qt-Libraries (e.g. Zeal) instead of my native Gtk based environment, it is a candidate for Flatpak. Marker is now in native repos of Arch, therefore is use it now from there. While I kept OpenRA as Flatpak because I need usually the on provided by upstream. I think Flatpak is ideal for new stuff and especially closes-source software. Programmers cannot do the repeated error of supporting some special outdated distributions. It is a miracle to me how anyone can think that packing for a specific distro is their job? It is not. The job is documenting how to package the software and allow redistribution. With Flatpak we allow them to do package themself if desired but just once and for all. A weak point of Flatpak is that facepalm Canonical is doing it very own show with Snap. How often does Canonical need to fail with Mir, Unity, Upstart and now Snap? The server is closed-source and it is against the community. Even if it would be better it is dead. And no, we don’t need two competing…please just commit fixes to GNOME e.g. type-ahead-find? And I don’t want to hype Flatpak: GNOME-Software could use less memory itself, we need an easy approach for payment (and repeated payment?) and it stores many small file on disk. And I wonder which security requirements the Flathub requires?
  - ilyt 3y ago
    > A weak point of Flatpak is that facepalm Canonical is doing it very own show with Snap. How often does Canonical need to fail with Mir, Unity, Upstart and now Snap? The server is closed-source and it is against the community. Even if it would be better it is dead. And no, we don’t need two competing…please just commit fixes to GNOME e.g. type-ahead-find? Hey now, Canonical provides valuable service of researching how to not do something so others can avoid those mistakes.
- wheelerof4te 3y ago
  "It doesn't make sense for every single distro to maintain customized versions of user level applications" Why it needs to be a customized package? Software is software and every Linux application which is open-source can be compiled and placed in /usr/local or whatever non-system level directory. Why is it so hard to compile the latest supported version and package it in a distro-agnostic way?
  - Gigachad 3y ago
    It isn't that hard, that's exactly what flatpak is doing.
    - wheelerof4te 3y ago
      Flatpak requires runtimes, not libraries. Most devel libraries don't take up GBs of disk space as Flatpak runtimes do. Also, Flatpak apps are containerized. That usually means they aren't bare metal.
- JohnFen 3y ago
  I sure hope that flatpack doesn't become the only way to use LibreOffice. Flatpack is a nonstarter, and building it from source would be a royal pain.
tlamponi 3y ago
Well your excerpts aren't really clearing up all confusion IMO, but even the original message is somewhat confusing too: >> … will contribute some fixes upstream to ensure LibreOffice works better as a Flatpak, which we expect to be the way that most people consume LibreOffice in the long term. Here you left out the part that they'll do that only until older RHEL releases, that still have LibreOffice support are EOL: > We will continue to maintain LibreOffice in currently supported versions of RHEL (RHEL 7, 8 and 9) > with needed CVEs and similar for the lifetime of those releases (as published on the Red Hat > website). As part of that, the engineers doing that work will contribute some fixes upstream to > ensure LibreOffice works better as a Flatpak, which we expect to be the way that most people > consume LibreOffice in the long term. I.e., they don't plan to fix anything besides issues w.r.t. the (only older?) release branches supported by RHEL <= 9, until that is EOL too. And while they first hint that only RPMs packages are affected and implicitly suggest that distribution via Flatpack is the way forward (yuck), they then contradict that part by telling that they'd find it OK if a volunteer picks up LibreOffice support for both, RPM and Flatpack, up again in Fedora. I.e., reading that it seems that they don't plan to actually support the Flatpack distribution either? Or is this a Fedora specific Flatpack repo?
- bonzini 3y ago
  No, they plan to maintain the RPMs for RHEL 7/8/9 and to contribute fixes for Flatpak, which is how they expect people to consume LO (without Red Hat support) in RHEL 10 and perhaps in future Fedora releases. I for one am a periodic LO user (for both work stuff and personal sheets like tax returns) on Fedora and will switch next week to Flatpak to start reporting bugs. I already use Flatpak for OBS, Ferdium and VSCode, with no issues except that I need to use ssh access to open VSCode projects on localhost (because of some known sandboxing issues). > support for both, RPM and Flatpak, up again in Fedora Fedora has a Flatpak repository that is separate from FlatHub. LibreOffice developers post their builds to FlatHub, and those are usable from Fedora without involvement from Fedora developets.
  - tlamponi 3y ago
    > Fedora has a Flatpak repository that is separate from FlatHub. Yeah, it sounded a bit like this, but with all those comments here and LWN I started to get confused myself. And I definitively could have just looked it up so appreciate it all the more that you cleared it up to me, many thanks!
dang 3y ago
Ok, we've changed to that from https://lwn.net/Articles/933525/ https://lwn.net/Articles/933525/. Thanks!
- Kailhus 3y ago
  You just never stop, you’re a beautiful human
  - dang 3y ago
    if only changing links could make one a beautiful human... (but thanks!)
gigatexal 3y ago
Why don’t the libreoffice devs package a flatpak as a first party thing?

Gigachad 3y ago

This is probably how things will be moving. It doesn't make sense for every single distro to maintain customized versions of user level applications now that we have one package that works everywhere.

ekianjo 3y ago
Works everywhere is a stretch. Flatpaked applications have multiple issues
- qbasic_forever 3y ago
  Bespoke RPMs that have to be patched and modified for distros by a small group of maintainers have issues too.
  - b112 3y ago
    Redhat is just falling. It was a pain doing packages 25 years ago, comparatively it is simple now. Frankly, the flatpak will have issues as well, but those will be outside of Redhat's direct control. Which means the end game, will be a redhat flatpak.
    - worthless-trash 3y ago
      Red Hat will almost definitely work with upstream to "fix the problem". Red Hat engineerings mantra is "Upstream first", the financial cost of maintaining a difference from upstream is a detractor to encourage users from using upstream builds.
contrarian1234 3y ago
You're talking about AppImages right? I've tried several times to understand how Flatpak works and how to integrate a CMake build with Flatpak.. and I'm honestly befuddled. Granted a quick Google search does show the situation has improved a bit in the past year. I imagine if you're trying to package a Zig or Clojure application it's going to be a lot of figuring things out on your own
- Laaas 3y ago
  Flatpak is quite simple under the hood, it's just a wrapper around bubblewrap [0]. I'm not sure what you mean with integrating it with a CMake build. [0]: https://github.com/containers/bubblewrap https://github.com/containers/bubblewrap
- dale_glass 3y ago
  AppImage is also troublesome. I just spent a good while debugging ours. The TL;DR is that AppImage amounts to a self-extracting archive, and you need an application where all the binaries and libraries have a relative rpath. So rather than loading /usr/lib/libz.so, it uses $BINARY/../lib/libz.so. That part's not too bad, but what can cause a lot of trouble is that there's a fair amount of stuff that uses dlopen at runtime. So you might find that you think you packaged everything, but then the app loads some module from the host system, the API isn't compatible and it explodes in some confusing fashion. So yeah, Linux app distribution is a pain no matter what it seems.
  - duped 3y ago
    Can't you just add an rpath to your main executable (which cmake does by default for release builds that aren't installed, fwiw) or use a launcher that sets LD_LIBRARY_PATH?
    - dale_glass 3y ago
      You can, the trouble is that you don't know that say, libfoo.so loads libbar.so at runtime, and so you need to also package up libbar.so. Otherwise, libbar.so won't be found in your AppImage, will get loaded from the host instead, and now it explodes but only on some distributions. In my case it was OpenSSL loading stuff at runtime.
creatonez 3y ago
> It doesn't make sense for every single distro to maintain customized versions of user level applications now that we have one package that works everywhere. It does make sense for at least one distro to be offering this, as there are numerous reasons to favor the traditional linux distro way of doing things. Flatpak is better for a lot of use cases, but it's missing a lot by not having a centralized system of checks and balances provided by a Linux distro. Fedora Flatpak brings back a lot of the advantages of traditional Linux distributions, but unfortunately Fedora/RHEL likely won't be maintaining a Fedora Flatpak version of LibreOffice.
- Conan_Kudo 3y ago
  New maintainers picked up LibreOffice, so that will still happen, since LibreOffice wasn't retired from Fedora.
  - ladyanita22 3y ago
    Did they? I understand then that users may still get the EPEL libreoffice.
bandrami 3y ago
Flatpak is a non-starter for me. The runtimes required by my office would mean 2 KDE versions and 2 Gnome versions installed as flatpak runtimes in addition to the KDE running on the host, which quintuples the security space I need to monitor. Sweeping package management problems under a rug doesn't actually make them go away.
- dralley 3y ago
  Flatpaks unlike Snaps are actually sandboxed properly.
  - seabass-labrax 3y ago
    Just being sandboxed though isn't a help if you actively want the software to process sensitive data! If you want to read a private document in LibreOffice, you have to be sure your copy of LibreOffice and every library it calls is trustworthy and reasonably secure.
    - yjftsjthsd-h 3y ago
      I dunno, if it's sandboxed and doesn't have network access then the only attacks I can think of are either really indirect (embedding an attack in saved files in hopes of hitting another user) or really targeted (altering a specific document or phrase when it's read). Assuming the sandbox works and includes blocking of network access, what attack do you see a word processor performing even when handed sensitive data?
      - bluGill 3y ago
        Most word processors have some web abilities. Click and link and the web browser opens. That link can be custom crafted to send data.
      - iudqnolq 3y ago
        Suppose your word processor is allowed to write to arbitrary files in your home directory. It writes a line into your .profile that CURLs your sensitive data to it's server. This has a level of indirection, but that just delays things until the next login. With a little more work there are infinite other places you could inject that might run sooner.
ho_schi 3y ago
Because there are pros and cons for each type of packaging but native distro packages and Flatpak will go-exist. It does already on my machine. Distribution packages: + necessary for base system + small memory requirement + small package size + all checked by distro + work well together + on fix, fixes it for all o lot of work for maintainers downstream - bugs hard to figure out for upstream - problematic with closed-source Flatpak: + programmer packages is/her software once and only once + support all distributions i.e. Linux + use selected dependencies + control-groups and namespace are in place for lock-in + autonomous offline package handling e.g. “storeable on thumbdrive” - huge maintenance burden, especially security, on programmer - higher memory usage - big package size Usually if I see something entirely new (e.g. Marker some years ago) or something using Qt-Libraries (e.g. Zeal) instead of my native Gtk based environment, it is a candidate for Flatpak. Marker is now in native repos of Arch, therefore is use it now from there. While I kept OpenRA as Flatpak because I need usually the on provided by upstream. I think Flatpak is ideal for new stuff and especially closes-source software. Programmers cannot do the repeated error of supporting some special outdated distributions. It is a miracle to me how anyone can think that packing for a specific distro is their job? It is not. The job is documenting how to package the software and allow redistribution. With Flatpak we allow them to do package themself if desired but just once and for all. A weak point of Flatpak is that facepalm Canonical is doing it very own show with Snap. How often does Canonical need to fail with Mir, Unity, Upstart and now Snap? The server is closed-source and it is against the community. Even if it would be better it is dead. And no, we don’t need two competing…please just commit fixes to GNOME e.g. type-ahead-find? And I don’t want to hype Flatpak: GNOME-Software could use less memory itself, we need an easy approach for payment (and repeated payment?) and it stores many small file on disk. And I wonder which security requirements the Flathub requires?
- ilyt 3y ago
  > A weak point of Flatpak is that facepalm Canonical is doing it very own show with Snap. How often does Canonical need to fail with Mir, Unity, Upstart and now Snap? The server is closed-source and it is against the community. Even if it would be better it is dead. And no, we don’t need two competing…please just commit fixes to GNOME e.g. type-ahead-find? Hey now, Canonical provides valuable service of researching how to not do something so others can avoid those mistakes.
wheelerof4te 3y ago
"It doesn't make sense for every single distro to maintain customized versions of user level applications" Why it needs to be a customized package? Software is software and every Linux application which is open-source can be compiled and placed in /usr/local or whatever non-system level directory. Why is it so hard to compile the latest supported version and package it in a distro-agnostic way?
- Gigachad 3y ago
  It isn't that hard, that's exactly what flatpak is doing.
  - wheelerof4te 3y ago
    Flatpak requires runtimes, not libraries. Most devel libraries don't take up GBs of disk space as Flatpak runtimes do. Also, Flatpak apps are containerized. That usually means they aren't bare metal.
JohnFen 3y ago
I sure hope that flatpack doesn't become the only way to use LibreOffice. Flatpack is a nonstarter, and building it from source would be a royal pain.

tlamponi 3y ago

Well your excerpts aren't really clearing up all confusion IMO, but even the original message is somewhat confusing too: >> … will contribute some fixes upstream to ensure LibreOffice works better as a Flatpak, which we expect to be the way that most people consume LibreOffice in the long term. Here you left out the part that they'll do that only until older RHEL releases, that still have LibreOffice support are EOL: > We will continue to maintain LibreOffice in currently supported versions of RHEL (RHEL 7, 8 and 9) > with needed CVEs and similar for the lifetime of those releases (as published on the Red Hat > website). As part of that, the engineers doing that work will contribute some fixes upstream to > ensure LibreOffice works better as a Flatpak, which we expect to be the way that most people > consume LibreOffice in the long term. I.e., they don't plan to fix anything besides issues w.r.t. the (only older?) release branches supported by RHEL <= 9, until that is EOL too. And while they first hint that only RPMs packages are affected and implicitly suggest that distribution via Flatpack is the way forward (yuck), they then contradict that part by telling that they'd find it OK if a volunteer picks up LibreOffice support for both, RPM and Flatpack, up again in Fedora. I.e., reading that it seems that they don't plan to actually support the Flatpack distribution either? Or is this a Fedora specific Flatpack repo?

bonzini 3y ago
No, they plan to maintain the RPMs for RHEL 7/8/9 and to contribute fixes for Flatpak, which is how they expect people to consume LO (without Red Hat support) in RHEL 10 and perhaps in future Fedora releases. I for one am a periodic LO user (for both work stuff and personal sheets like tax returns) on Fedora and will switch next week to Flatpak to start reporting bugs. I already use Flatpak for OBS, Ferdium and VSCode, with no issues except that I need to use ssh access to open VSCode projects on localhost (because of some known sandboxing issues). > support for both, RPM and Flatpak, up again in Fedora Fedora has a Flatpak repository that is separate from FlatHub. LibreOffice developers post their builds to FlatHub, and those are usable from Fedora without involvement from Fedora developets.
- tlamponi 3y ago
  > Fedora has a Flatpak repository that is separate from FlatHub. Yeah, it sounded a bit like this, but with all those comments here and LWN I started to get confused myself. And I definitively could have just looked it up so appreciate it all the more that you cleared it up to me, many thanks!

dang 3y ago

Ok, we've changed to that from https://lwn.net/Articles/933525/ https://lwn.net/Articles/933525/. Thanks!

Kailhus 3y ago
You just never stop, you’re a beautiful human
- dang 3y ago
  if only changing links could make one a beautiful human... (but thanks!)

gigatexal 3y ago

Why don’t the libreoffice devs package a flatpak as a first party thing?