Red Hat dropping support for LibreOffice
Red Hat dropping support for LibreOffice
Posted Jun 3, 2023 11:16 UTC (Sat) by pbonzini (subscriber, #60935)In reply to: Red Hat dropping support for LibreOffice by Wol
Parent article: Red Hat dropping support for LibreOffice
Posted Jun 3, 2023 11:56 UTC (Sat)
by gbraad (guest, #42498)
[Link] (22 responses)
Posted Jun 3, 2023 15:09 UTC (Sat)
by tlamp (subscriber, #108540)
[Link] (6 responses)
The software developers often (most of the time IME) not packaging experts, especially not for a variety of operating systems and different distributions, but the packagers of the distribution are experts for theirs, and can ensure that it's actually well integrated and handles updates correctly from the POV of the whole distribution.
I know a lot of good software engineers that have a hard time doing a release inclusive upgrade and maintenance procedure handling any config movements and breaking changes and what not, as they ain't release manager or maintainers of a distribution and that can be fine, not everyone needs to be able to do everything.
Also, packaging _is_ a lot of work, but if there are experienced people doing it correctly the end result is a marvel.
Sure, XDG, dbus and a few such things helped that at least the basics can still work, but it will never have that level of integration, and it will definitively not profit from any specific feature of the distributions package management.
And don't get me wrong, Flatpack or other such channels are _far_ better from nothing, and if there's a paclage but the distribution (or the specific maintainer) cannot keep up with newer versions of upstream they can even help to move away pressure from them.
Posted Jun 3, 2023 23:35 UTC (Sat)
by gbraad (guest, #42498)
[Link] (1 responses)
Posted Jun 5, 2023 12:45 UTC (Mon)
by jonesmz (subscriber, #130234)
[Link]
That sounds a lot like a bug in the package then.
Posted Jun 4, 2023 0:16 UTC (Sun)
by rjones (subscriber, #159862)
[Link] (3 responses)
What is the major advantage for packagers to work on the distribution level versus the application project level?
This way their expertise benefits everybody, not just the users of a specific distribution release version. That way the same work doesn't need to be repeated for each and other distribution release all around the world. And people can spend time on fixing other technical debt in the OS or working with other projects to package their software, etc.
Posted Jun 4, 2023 1:50 UTC (Sun)
by intelfx (subscriber, #130118)
[Link] (2 responses)
What is the major advantage for packagers to work on the distribution level versus the application project level?
There absolutely is a reason. It's called integration: you cannot perform integration work in vacuum. Distribution work is 10% packaging and 90% integration, and the "major advantage" for packagers to work on the distribution level is that the distribution provides a framework for all of the integration decisions.
Posted Jun 4, 2023 8:44 UTC (Sun)
by coriordan (guest, #7544)
[Link]
Upstream might put in some settings or features that are desireable for upstream but aren't good for users (ads, phoning home, gathering data, pushing a particular file format...), but the package managers can fix this before it gets sent to the user.
Of course, package managers can also have a conflict of interest, but a distribution relies on the trust of its users. If I don't trust DistroABC, I can switch to Debian or whatever. Having two independent teams in the supply chain ensures that the software is as the user would want it.
Posted Jun 6, 2023 19:26 UTC (Tue)
by bartoc (guest, #124262)
[Link]
Posted Jun 3, 2023 15:11 UTC (Sat)
by mb (subscriber, #50428)
[Link] (4 responses)
In my experience it's absolutely the other way around. I currently run Firefox and Fluffychat via flatpak and they are a constant stream of little and big incompatibility problems and other breakages. I never experienced that much breakage with native Debian packages.
Posted Jun 5, 2023 14:50 UTC (Mon)
by geert (subscriber, #98403)
[Link]
Posted Jun 6, 2023 9:13 UTC (Tue)
by MarcB (subscriber, #101804)
[Link] (2 responses)
Nice example: https://github.com/keepassxreboot/keepassxc/issues/8876 (the issue is generic to GVFS)
This issue is apparently known in one form or another since 2019. It happens for Flatpak and Snap. The exact root cause likely varies between different version of GVFS.
The AppImage version works, but it is not using GNOME file dialogs. The only version that works perfectly, is the .deb package.
I am absolutely not impressed with upstream packaged software, but also not surprised: development and integration are very different things and require very different skill sets. The assumption that developers are good at packaging - or that they fully understand their software and its interaction with other components - is simply wrong.
Posted Jun 6, 2023 10:39 UTC (Tue)
by MarcB (subscriber, #101804)
[Link]
The cursor disappears, because the flatpaked application is not allowed to access the icons at certain locations.
This is exactly the type of issue developers are notoriously bad at, but which integrators are constantly dealing with.
Posted Jun 6, 2023 15:29 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
As somebody who has written a makefile (for a very simple piece of software, and assuming nothing more than a modern linux system) I can only concur.
I wrote it and it worked fine on my gentoo system. Then somebody tried to run it on - Red Hat I believe - and it fell over in a heap.
Systemd may have brought distros closer together, but there's still plenty of landmines for unwary developers cum packagers.
Cheers,
Posted Jun 3, 2023 16:43 UTC (Sat)
by 0xbadcafebee (guest, #165443)
[Link] (2 responses)
As a packager, this is incorrect. Most software developers have no idea how to properly install or maintain their own software in a system. That's why we have to package it for them.
The system would be an unusable mess if packagers didn't fix all the software to install it properly and integrate it with the system. We fix build issues, patch the source code, and change all kinds of paths, to say nothing of dealing with the dependencies.
Posted Jun 6, 2023 21:25 UTC (Tue)
by hailfinger (subscriber, #76962)
[Link] (1 responses)
I can focus on providing software in source form which can be compiled reasonably easy on the most common platforms. Packagers take care of all the idiosyncrasies or their platform of choice and I can integrate most of that work into the next release, making life easier for me (no need to find out how to handle platform/distro X), for the packagers (most/all of their changes integrated) and for users (software will be installable from their repo of choice and/or compile out of the box on their target platform).
As a user, I am also thankful if software comes in a format native to the distribution and from a repository I trust.
I have seen enough developer-created run-anywhere packages with unfixed security issues in vendored libraries (after all, why would the developer want to regenerate the package if the main software is unchanged), horrible file system access integration (no access to /tmp, no access to custom locations outside $HOME) and bloated storage requirements (vendoring of already installed libraries consumes space). Plus, distributions usually test updates from one software version to another and old versions won't disappear on a whim.
Posted Jun 8, 2023 16:12 UTC (Thu)
by madhatter (subscriber, #4665)
[Link]
Posted Jun 4, 2023 13:58 UTC (Sun)
by LtWorf (subscriber, #124958)
[Link] (2 responses)
Gnome developers are convinced that to run gnome calculator you need to run network-manager, which will of course disconnect all connections you have configured outside of network-manager.
Posted Jun 4, 2023 14:19 UTC (Sun)
by intelfx (subscriber, #130118)
[Link] (1 responses)
How so?
> which will of course disconnect all connections you have configured outside of network-manager
We're wandering into off-topic territory here, but this is definitely untrue.
Posted Jun 7, 2023 21:44 UTC (Wed)
by koh (subscriber, #101482)
[Link]
Posted Jun 4, 2023 15:31 UTC (Sun)
by gspr (guest, #91542)
[Link]
Maybe they understand the software better. But that software has to coexist with, and usually interact with, thousands of other pieces of software. An operating system is more than the sum of its individual packages. In my opinion, distribution-based packagers do a far better job taking the whole system into account (indeed perhaps to the detriment of a single piece of software on a few rare occasions).
Posted Jun 5, 2023 4:44 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
Imagine if software creators had to package their own software to run it after each one-line change...
Many developers barely understand the _build system_ of the project they spend their entire days on.
Posted Jun 5, 2023 6:21 UTC (Mon)
by tamara_schmitz (guest, #141258)
[Link] (1 responses)
Posted Jun 10, 2023 21:28 UTC (Sat)
by DemiMarie (subscriber, #164188)
[Link]
Red Hat dropping support for LibreOffice
Red Hat dropping support for LibreOffice
Red Hat dropping support for LibreOffice
Red Hat dropping support for LibreOffice
Red Hat dropping support for LibreOffice
Red Hat dropping support for LibreOffice
Red Hat dropping support for LibreOffice
Red Hat dropping support for LibreOffice
Red Hat dropping support for LibreOffice
Red Hat dropping support for LibreOffice
Red Hat dropping support for LibreOffice
Depending on your typical usage, you will never encounter this issue. But in my case, it is a showstopper.
Red Hat dropping support for LibreOffice
Red Hat dropping support for LibreOffice
Wol
Red Hat dropping support for LibreOffice
Red Hat dropping support for LibreOffice
Red Hat dropping support for LibreOffice
Red Hat dropping support for LibreOffice
Red Hat dropping support for LibreOffice
Red Hat dropping support for LibreOffice
Red Hat dropping support for LibreOffice
Red Hat dropping support for LibreOffice
Red Hat dropping support for LibreOffice
Firefox PIE