I use libreoffice-bin instead of libreoffice and this is the result:
# emerge libreoffice-l10n -pu
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] dev-util/cppunit-1.13.0 USE="-doc -examples -static-libs"
[ebuild N ] net-misc/npapi-sdk-0.27
[ebuild N ] dev-perl/Archive-Zip-1.300.0
[ebuild N ] media-libs/libcdr-0.0.8 USE="-doc -static-libs"
[ebuild U ] dev-cpp/libcmis-0.2.3 [0.1.0] USE="-man%"
[ebuild N ] dev-util/mdds-0.6.0-r2
[ebuild N ] dev-cpp/clucene-18.104.22.168-r3 USE="-debug -doc -static-libs"
[ebuild U ] app-office/libreoffice-l10n-3.6.0 [3.5.5] LINGUAS="-am% -bn_IN%"
[blocks B ] app-office/libreoffice ("app-office/libreoffice" is blocking app-office/libreoffice-bin-22.214.171.124)
[blocks B ] app-office/libreoffice-bin ("app-office/libreoffice-bin" is blocking app-office/libreoffice-126.96.36.199)
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
(dev-cpp/libcmis-0.2.3::gentoo, ebuild scheduled for merge) pulled in by
>=dev-cpp/libcmis-0.2 required by (app-office/libreoffice-188.8.131.52::gentoo, ebuild scheduled for merge)
(dev-cpp/libcmis-0.1.0::gentoo, installed) pulled in by
<dev-cpp/libcmis-0.2 required by (app-office/libreoffice-bin-184.108.40.206::gentoo, installed)
=dev-cpp/libcmis-0.1* required by (app-office/libreoffice-bin-220.127.116.11::gentoo, installed)
It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously. If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously.
For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.
I get this too. "emerge -u @world" wants to install libreoffice, even though I use libreoffice-bin.
Note: I'm not doing "emerge -u libreoffice-l10n". I'm doing a world update.
app-office/libreoffice-bin-18.104.22.168 missing in portage tree.
I also only have libreoffice-bin installed.
I cannot solve this by masking libreoffice, it still gets pulled in.
So my world update gets also hindered.
You also need to mask =app-office/libreoffice-l10n-3.6.0.
(In reply to comment #4)
> You also need to mask =app-office/libreoffice-l10n-3.6.0.
The binaries are provided only for stable systems, so the bin will be provided at the time it gets stabilised.
You can decide yourself if you want to migrate to source version, or rely on stable release.
We simply lack the resources to rebuild the libreoffice binary every other day due to library updates.
(In reply to comment #6)
> So what?
libreoffice-l10n should not depend on libreoffice but the other way around?
(In reply to comment #7)
> (In reply to comment #6)
> > So what?
> libreoffice-l10n should not depend on libreoffice but the other way around?
Briliant, but no.
Those help files require version of libreoffice newer than expressed by the dependency there. Otherwise it just breaks on runtime.
You can't use 3.6 translations in 3.5 libreoffice, it is not gettext stuff.
You can try replace those >= deps with !< and see if portage can cope with it better. If so we can replace it, otherwise it stays in place.
Ah, nice. Another portage brain damage. It seems we're using the most advanced Linux distro out there. Way to go.
Isn't it some sort of a Gentoo rule that a package can't depend on another package that is not in the main tree?
(In reply to comment #9)
> Ah, nice. Another portage brain damage. It seems we're using the most
> advanced Linux distro out there. Way to go.
Why the hell it should be brain damage?
It calculates the depgraph correctly and prints cleanest resolution of the deps in the testing tree. I agree that the default message is bit confusing but if you would bother to use the --tree parameter it would even show you why the hell it is happening. This collision really requires manual intervention.
Anyway I updated all the deps in -bin source -l10n to depend more strictly so now the blocker will be printed bit differently which should be more easily understanded why it is happening without having to use more parameters. And still it will require manual intervention if you preffer to stay on -bin version if anyone has the l10n in world file or any set without version.
Also as I stated multiple times, if you run -bin with testing tree do not expect it to be supported (ever) so consider trying the source version. It compiles 1.5x longer than chromium, which most of you guys compile anyway without a problem.
(In reply to comment #10)
> Isn't it some sort of a Gentoo rule that a package can't depend on another
> package that is not in the main tree?
Yes it should not depend on package that is not in main tree, but as you can see there was or conditional, and then there must be at least one of those sattified by the tree.
I find it amazing that all this breakage makes so much perfect sense to you.