Summary: | app-office/libreoffice-l10n-3.6.0 depends on app-office/libreoffice-bin-3.6.0 which is not in the tree | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | PM <mitaspiotr> |
Component: | Current packages | Assignee: | Gentoo Office Team <office> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | CC: | alexandre.guimaraes, jrmalaq, jwbraun, krinpaus, realnc, saintdev, steffen.weber, u.plate |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
PM
2012-08-08 15:27:02 UTC
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. Also: app-office/libreoffice-bin-3.6.0.4 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. Thanks :) So what? 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. |