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

Code: Select all

BIN_COMMON_DEPEND="
        =app-text/libexttextcat-3.4*
        app-text/poppler:0/35
        =dev-libs/boost-1.49*
(...)

This translates for /etc/portage/package.mask as

Code: Select all

>app-text/libexttextcat-3.4.0
>app-text/poppler-0.22.2-r2
>dev-libs/boost-1.49.0-r2
(...)

Made sticky. -- desultory

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

Code: Select all

# While app-office/libreoffice-bin catches up
>app-text/libexttextcat-3.4.0
>app-text/poppler-0.22.2-r2
>dev-libs/boost-1.49.0-r2 
(...)

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

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

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?

[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:

Code: Select all

>app-text/poppler-0.22.5

[Havin_it]

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

Code: Select all

>app-text/poppler-0.22.5

For now ... give it a week or two until the other libs are updated

Thanks to dilfridge and NeddySeagoon for some clear-cut user-level explanation of this issue and what we can do about 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]

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.

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.

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.

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

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

Code: Select all

  (dev-libs/icu-51.1::gentoo, installed) pulled in by
    dev-libs/icu:0/51.1= required by (media-libs/harfbuzz-0.9.23::gentoo, installed)
    >=dev-libs/icu-49:0/51.1= required by (dev-qt/qtcore-4.8.5-r1::gentoo, installed)
    dev-libs/icu:0/51.1= required by (dev-qt/qtwebkit-4.8.5::gentoo, installed)
    dev-libs/icu:0/51.1= required by (dev-lang/v8-3.20.17.15::gentoo, installed)
    dev-libs/icu:0/51.1= required by (dev-libs/libxml2-2.9.1-r1::gentoo, installed)
    dev-libs/icu:0/51.1= required by (dev-db/sqlite-3.8.2::gentoo, installed)
    dev-libs/icu:0/51.1= required by (sys-apps/gptfdisk-0.8.8::gentoo, installed)
    (and 1 more with the same problems)

  (dev-libs/icu-51.2-r1::gentoo, ebuild scheduled for merge) pulled in by
    dev-libs/icu:0/51.2 required by (app-office/libreoffice-bin-4.1.4.2::gentoo, ebuild scheduled for merge)

when i check what on my systems depends on icu,
i noticed that no package requires exactly version 51.0.

Code: Select all

E09 k4tfish # equery d dev-libs/icu
 * These packages depend on dev-libs/icu:
dev-db/sqlite-3.8.2 (icu ? dev-libs/icu)
dev-lang/v8-3.20.17.15 (dev-libs/icu:0)
dev-libs/boost-1.52.0-r6 (icu ? >=dev-libs/icu-3.6)
dev-libs/libxml2-2.9.1-r1 (icu ? dev-libs/icu)
dev-qt/qtcore-4.8.5-r1 (icu ? >=dev-libs/icu-49)
dev-qt/qtwebkit-4.8.5 (icu ? dev-libs/icu)
media-libs/harfbuzz-0.9.23 (icu ? dev-libs/icu)
net-libs/webkit-gtk-1.8.3-r201 (>=dev-libs/icu-3.8.1-r1)
net-nds/openldap-2.4.35-r1 (icu ? dev-libs/icu)
sys-apps/gptfdisk-0.8.8 (icu ? dev-libs/icu)
                        (icu ? dev-libs/icu[static-libs(+)])

so whats right now? equery or emerge? Pls enlight me.

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

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

best ... khay

[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:

Code: Select all

configure: error: cannot find the flags to link with Boost program_options

!!! Please attach the following file when seeking support:
!!! /var/tmp/portage/dev-libs/libixion-0.11.1/work/libixion-0.11.1/config.log
 * ERROR: dev-libs/libixion-0.11.1::gentoo failed (configure phase):
 *   econf failed
 * 
 * Call stack:
 *               ebuild.sh, line  115:  Called src_configure
 *             environment, line 3014:  Called econf '--disable-python' '--disable-static'
 *        phase-helpers.sh, line  665:  Called __helpers_die 'econf failed'
 *   isolated-functions.sh, line  117:  Called die
 * The specific snippet of code:
 *              die "$@"
 * 

Additional info:

Code: Select all

emerge --info '=dev-libs/libixion-0.11.1::gentoo'

Results: https://paste.debian.net/hidden/d10ae23d/

Code: Select all

emerge -pqv '=dev-libs/libixion-0.11.1::gentoo'

Results: [ebuild N ] dev-libs/libixion-0.11.1 USE="-python -static-libs" PYTHON_SINGLE_TARGET="python3_4 (-python3_5)" PYTHON_TARGETS="python3_4 (-python3_5)"

Code: Select all

/var/tmp/portage/dev-libs/libixion-0.11.1/temp/environment

Results: https://paste.debian.net/hidden/62d19680/

Code: Select all

/var/tmp/portage/dev-libs/libixion-0.11.1/temp/build.log

Results: https://paste.debian.net/hidden/bcf64d51/

[fedeliallalinea]

Can help this?

[tld]

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

Code: Select all

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

app-text/hunspell:0

  (app-text/hunspell-1.3.3:0/0::gentoo, installed) pulled in by
    >=app-text/hunspell-1.2:0/0= required by (www-client/firefox-45.7.0:0/0::gentoo, installed)
                           ^^^^^                                                                                                   

  (app-text/hunspell-1.6.1-r1:0/1.6::gentoo, ebuild scheduled for merge) pulled in by
    app-text/hunspell:0/1.6 required by (app-office/libreoffice-bin-5.2.6.2:0/0::gentoo, ebuild scheduled for merge)

Correct me if I'm wrong, but I'm assuming that all I can do for now is to mask the newer libreoffice version until (when/if) some newer version of firefox happens to use the newer version of hunspell(?).

Thanks
Tom

[fedeliallalinea]

You need only rebuild firefox with newer hunspell

Code: Select all

# emerge -1 app-text/hunspell:0/1.6 firefox

[tld]

You need only rebuild firefox with newer hunspell

Code: Select all

# emerge -1 app-text/hunspell:0/1.6 firefox

Ahh...right. I think I'll wait until the next time I actually need to compile FF though.
One thing confuses be a little bit here: Since app-text/hunspell-1.6.1-r1 is stable, what actually prevented emerge from wanting to pull that in and recompile FF? Mind you I wouldn't actually want it too...I just don't quite follow why it didn't.
Thanks!

[saturnalia0]

Can help this?

That solved it, thanks.