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

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.

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.

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
andy@andyfigueroa.us Working with Unix since 1983.

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)?

I think the problem relies upstream: until libreoffice ships a version that uses updated libraries we're stuck there.
Might be worth checking on their bugtracker maybe?_________________Gentoo user since 2004.
"It's all fun and games, until someone loses an eye" - mom

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...

Wouldn't it be possible to bundle the libraries for the gentoo-specific libreoffice-bin as they do in upstream?

Possible, certainly. Desirable, no. It's not the Gentoo Way(TM), and the reasons for this are well-thought-out, I promise.

julakali wrote:

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?

Not that useful a comparison, things are different on many levels between these two. Firefox upstream is updated very frequently in response to security bugs; LO, not so much. Firefox-bin is built against mostly in-tree versions of critical core libs that don't update and break ABI every 5 minutes; look at the binaries with ldd to see what I mean. Some of LO's dependencies are "nightmare libs" that break ABI constantly and don't care because few people/things use them. This in turn makes Firefox a whole lot easier for Gentoo devs to build, test and release it across all arches quite swiftly after the upstream release.

julakali wrote:

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...

I think you overestimate how many people have the resources to do this. Even on a brand-new PC, that takes serious time and grunt to complete, and many of us won't willingly tie up machines for that long when we may actually need to *use* them. The very existence of *-bin packages is testament to that. If I actually needed an office suite more than once in a blue moon, I'd probably switch back to OOo-bin (assuming that's not subject to the same problems right now). I hear Calligra's pretty nice too... As it is, I just uninstalled LO because neither package, src or bin, is worth the effort: I can view ODFs and DOCs in Okular, if I even need to do that.

All that said (and I'm sorry if it came across a bit combative), I do think this situation is pretty untenable. Packages this difficult to keep in-tree are usually farmed out to an overlay, and I think it's only the risk of open revolt that prevents this happening already in LO-bin's case.

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

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>

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.

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?]

[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?]

Havin_it ... its probably due to spam post that was then removed ... a topic reply notice is sent out immediately, but by the time you came to check the post a moderator had since relocated it to the dustbin.