Currently, there is only libreoffice-bin-24.2.7.2.ebuild, which is the only package (afaik) that still depends on boost-1.85.0.1, holding systems back. Upstream, LibreOffice stable is at 24.8.4 and unstable (~) at 25.2.0, But the problem lies elsewhere: Currently, the SRC_URI file is hosted at https://tamiko.43-1.org/distfiles/, which appears to be an unrelated private user’s server. And there is no information on how to turn the files at libreoffice.org into the ones at tamiko.43-1.org. (it isn’t just --buildpkg, is it?). So since libreoffice.org already provides binary packages, I propose writing a new ebuild that uses and transforms those files directly. Saving maintenance work in the future, and making keeping up with upstream trivial. (Just checking if the dependencies still match.) Reproducible: Always Steps to Reproduce: 1. emerge -auDNtv @world Actual Results: Emerge complains with a conflict with boost, as libreoffice-bin still requires old boost-1.85.0.1, while everything else would like to use new boost-1.87.0. It also will keep app-office/libreoffice-bin-24.2.7.2, as that is the only version available. Expected Results: On ~amd64, app-office/libreoffice-bin-25.2.0 should install, and >=boost-1.87.0 should be pulled in. I would make a new ebuild myself, if I knew what exactly the actions are, to turn upstream into a file for SRC_URI.
libreoffice-bin is a stable-only package, as such it cannot depend on a boost version that is far away from stabilisation.
(In reply to Navid Zamani from comment #0) > Currently, there is only libreoffice-bin-24.2.7.2.ebuild, which is the only > package (afaik) that still depends on boost-1.85.0.1, holding systems back. > > Upstream, LibreOffice stable is at 24.8.4 and unstable (~) at 25.2.0, > But the problem lies elsewhere: > > Currently, the SRC_URI file is hosted at https://tamiko.43-1.org/distfiles/, > which appears to be an unrelated private user’s server. And there is no > information on how to turn the files at libreoffice.org into the ones at > tamiko.43-1.org. (it isn’t just --buildpkg, is it?). > It's from a very long-standing Gentoo developer. It's just not on dev.gentoo.org as it takes up a lot of space. We have Manifests + mirroring, so it doesn't make much difference to the user where it's hosted. I think the scripts for building it are somewhere (dilfridge would have them but we're at FOSDEM atm, ask when we're back if he misses it). > So since libreoffice.org already provides binary packages, I propose writing > a new ebuild that uses and transforms those files directly. Saving > maintenance work in the future, and making keeping up with upstream trivial. > (Just checking if the dependencies still match.) Please investigate that yourself a bit to see if it's feasible. If it uses dynamically linked libraries, it surely isn't. If it statically links Boost and friends, it may be workable. But as-is, this bug isn't really a particular request for anything.
Looking at LibreOffice_25.2.0_Linux_x86-64_deb.tar.gz, at least, it would perhaps be feasible to actually use the binaries, the issue would be that it's split over (many) .deb files, so we'd need to do some mangling to merge that together. (Same problem for the RPMs.)
I have a prototype.
Testing of the proposed ebuild in https://github.com/gentoo/gentoo/pull/40544 is welcome and encouraged.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c457c9dd713c383e1bcea3d2c1b443f961266fd8 commit c457c9dd713c383e1bcea3d2c1b443f961266fd8 Author: Sam James <sam@gentoo.org> AuthorDate: 2025-02-12 11:13:59 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-02-13 09:57:52 +0000 app-office/libreoffice-bin: add 25.2.0 (switch to upstream binaries) Switch to upstream built binaries. This aligns us with, say, www-client/firefox-bin and provides some benefits: * Not needing to manually rebuild the new binaries when e.g. new Boost is stabilised. * This version is parallel-installable with app-office/libreoffice, so testing can be done to compare our builds with upstream's when investigating bug reports. * We can update it ahead of app-office/libreoffice when bumping requires more labour. The primary downside is having less control over dependencies, but app-office/libreoffice-bin was always heavy on dependencies even when we built it, and IMO, beggars cannot be choosers. Closes: https://bugs.gentoo.org/949193 Signed-off-by: Sam James <sam@gentoo.org> app-office/libreoffice-bin/Manifest | 1 + .../libreoffice-bin/libreoffice-bin-25.2.0.ebuild | 128 +++++++++++++++++++++ 2 files changed, 129 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d7a55c23f69bea9e6ba334139805bbd1f5b07c54 commit d7a55c23f69bea9e6ba334139805bbd1f5b07c54 Author: Sam James <sam@gentoo.org> AuthorDate: 2025-02-13 10:06:35 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-02-13 10:06:35 +0000 app-office/libreoffice-bin: add 24.8.4 ... as material hopefully more suitable to stable, though we could add 24.2.7.2 or 24.2.7.2-alike too, I suppose. Not that this will get much testing as it's shadowed in ~arch. Bug: https://bugs.gentoo.org/949193 Signed-off-by: Sam James <sam@gentoo.org> app-office/libreoffice-bin/Manifest | 1 + .../libreoffice-bin/libreoffice-bin-24.8.4.ebuild | 128 +++++++++++++++++++++ 2 files changed, 129 insertions(+)
