app-office/libreoffice-bin dependency problems

[dilfridge]

In Gentoo, we're not using the binary LibreOffice packages as provided by upstream, but build our own Gentoo binaries. These use the current stable versions of our system libraries (as e.g. boost, poppler, ...), which guarantees e.g. that there are no open security issues. (As opposed to that, the binaries from the LibreOffice website contain bundled copies of these libraries.)

Problems occur as soon as newer versions of these libraries become available and are stabilized in Gentoo. app-office/libreoffice-bin still requires the old version then, which may give emerge a hard time figuring out what to do. As a consequence,

• app-office/libreoffice-bin is useful only for stable system users (because that is the library set that it is built against).
  
• Even on a stable system, library upgrades may lead to occasional difficulties. Whenever a critical library is upgraded, we will however provide a new app-office/libreoffice-bin version soon (rough time scale 2 weeks).
  

What can you do in the meantime while you are having trouble?

• Use app-office/libreoffice (the source version) instead of app-office/libreoffice-bin
  
• Use app-office/openoffice-bin instead (which uses the upstream binary package with bundled libraries)
  
• Mask the newer library versions. See below for how to do it.
  

How can you mask the new library versions?

• Have a look at the app-office/libreoffice-bin ebuild. Somewhere around line 60 it contains a variable declaration BIN_COMMON_DEPEND; this contains the specifications for the libraries that LibreOffice was built against.
  
• Use /etc/portage/package.mask to mask all newer versions of these libraries on your system.
  

As an example, for libreoffice-bin-4.0.4.2 we have

[NeddySeagoon]

Keep in mind for the future, that these packages are masked.

Once app-office/libreoffice-bin has a hew version, built against the new libraries, you will get the problem in reverse as the new libraries are masked.
Portage will tell you about this.

If you put a comment into /etc/portage/package.mask, to tell why the masks are there, it may even show you the comment.

[moodboom]

1) Really appreciate your efforts.
2) This approach makes for a lousy end-user experience. There are times when we need a newer package than stable (eg I need the latest boost for development) and that makes the libreoffice-bin situation even worse than you described.

I'll try to build from source. Thanks for the clear description of the situation.

[figueroa]

Today, it worked for me fine to just mask the latest stable boost and poppler. The sticky post at the top of this thread is one of the best developer explanations of an issue I've ever read. Nice going.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi

[zlm]

Thanks for the explanation.

[kspy]

Thank you dilfridge!
Tell me please, can be expected in the near future a new version binary package (with support >dev-libs/boost-1.49)?

[Peach]

[el_Salmon]

For the new version of libreoffice-bin (4.1.2.3), it was enough for me to include this line in package.mask:

[Havin_it]

[julakali]

Wouldn't it be possible to bundle the libraries for the gentoo-specific libreoffice-bin as they do in upstream?
And about the security issues: Aren't we using bundled libraries in firefox-bin as well?
And isn't a browser more exposed than an office application?

I'm going to build libreoffice from source now, and i guess most of the people will do so after figuring out and updating the package masks 2-3 times.
In consequence, the binary is useless as it costs more configuring time than it saves build-time...

[Havin_it]

[depontius]

At this point I have to add that this weekend I finished migrating my home systems from OpenOffice to LibreOffice. Two of the machines are relatively recent dual-core Athlon-IIs, and one is a quite old socket 939 Athlon 64. The first two are running libreoffice and the latter libreoffice-bin. (The ~amd64 version, to get around the poppler problem, since I did this install after the poppler upgrade.)

In only a week or two I've had to rebuild libreoffice at least 3 times, with the "little-r" in the portage display, and I haven't been able to get a clear picture about exactly what is forcing that rebuild. There's another rebuild waiting in the wings, when I checked yestarday I got the "little-r" again. (By the way, this isn't 3 rebuilds on two systems - it's 3 rebuilds on the first system where I installed it. I only recently installed the second system, so I have 2 rebuilds waiting in the wings. (Except the older system is getting repurposed as a server, so it won't be running libreoffice any more.)

So we can choose annoying because of library vintage issues on the binary ebuild, or annoying because of long and too-frequent rebuilds on the source ebuild.

I'm not meaning to shoot the messenger on this, nor am I meaning to annoy the gift horse. But there is a mildly irritating situation here, and I honestly dont' know the solution.
_________________
.sigs waste space and bandwidth

[Havin_it]

It's really the same problem in either case: certain libs update and break their ABI at a pace that's far faster than a big monolithic thing like LO can easily keep pace with. At least I think that's what the issue is.

Libraries eventually mature and get more stable once they're finished improving and growing, but until that happens, there are these growing pains. LO certainly isn't the only package on my system for which poppler makes trouble, but you can't criticise a lib dev too much for wanting to improve their product. <shrugs>

[potuz]

Hi there, I'd like to understand the problem with man-power mentioned in #490114. Is the issue that the arch teams are delaying too much in stabilizing app-office/libreoffice-bin or is it that the libreoffice team does not have the man power to build and stabilize on time? As I see it now, the build in the unstable branch won't work against a stable system either cause even the unstable branch has dependencies on old harfbuzz libraries. And if I understand Comment #16 in that bug, this new build even when it gets stabilized, it wont work against a stable system.

[Windmill]

So there's no way to have the last version of libreoffice without building it?

[katfish]

dilfridge, u say the bin version is made for stable systems.

why depends it on the newest icu libs then?

[queen]

Thanks dillfridge, NeddySeagon.

I always used sources, but at some point it took a lot of time to compile libreoffice and installed bin version. Now based on your advices, I will return back to regular libreoffice.

[Havin_it]

Just a thought (and as it's not been mentioned before, I expect it's probably not a useful one): would slotting the problematic libs be a possible way of coping with this issue?

I can see that it's perhaps a big ask of the various maintainers involved, particularly being for the sole benefit of one "non-essential" package, but there are those for whom libreoffice-bin is a big need and this ongoing problem must be a real PITA for them. Not to mention that may be seen as a bit of a blot on Gentoo's copybook that one of the best-known FOSS apps remains such a bugger to install (not my own view, I hasten to add).

Would this be technically unfeasible, or just too onerous a task to be judged worthwhile?

[OFFTOPIC: I just got a reminder email for this topic (although it doesn't appear anyone's posted), but the link it contained is incorrect. What's up with that?]

[khayyam]

[saturnalia0]

[Edit: Solution in the post below]

I see the sticky about versioning issues with libreoffice-bin deps, but I'm not sure if this is a versioning issue or not.

Summary of the error:

[fedeliallalinea]

Can help this?
_________________
Questions are guaranteed in life; Answers aren't.

[tld]

I ran into this one today attempting to upgrade to libreoffice-bin-5.2.6.2 from 5.2.3.3-r1:

[fedeliallalinea]

You need only rebuild firefox with newer hunspell

[tld]

[saturnalia0]