[ebuild N ] virtual/ooo-0 0 kB [ebuild N ] app-office/libreoffice-l10n-3.4.4-r1 USE="-offlinehelp -templa tes" LINGUAS="el en -af -ar -as -ast -be -bg -bn -bo -br -brx -bs -ca -ca_XV -cs -cy -da -de -dgo -dz -en_GB -en_ZA -eo -es -et -eu -fa -fi -fr -ga -gd -gl -gu -he -hi -hr -hu -id -is -it -ja -ka -kk -km -kn -ko -kok -ks -ku -lo -lt -lv -ma i -mk -ml -mn -mni -mr -my -nb -ne -nl -nn -nr -nso -oc -om -or -pa_IN -pl -pt - pt_BR -ro -ru -rw -sa_IN -sat -sd -sh -si -sk -sl -sq -sr -ss -st -sv -sw_TZ -ta -te -tg -th -tn -tr -ts -ug -uk -uz -ve -vi -xh -zh_CN -zh_TW -zu" 8,080 kB [blocks B ] <=app-office/libreoffice-3.4.4.2-r1 ("<=app-office/libreoffice- 3.4.4.2-r1" is blocking app-office/libreoffice-l10n-3.4.4-r1) These blockers make no sense. There is no higher (non-live) version of libreoffice so what should we do? Thanks
Hmm I thought portage will just ignore the update... Could this depstring solve it instead those blockers? || ( >=app-office/libreoffice-3.4.4.2-r1 >=app-office/libreoffice-bin-3.4.3.2-r1 )
And it make perfect sense the l10n is shared among all versions of lo. Currently only live suffice the removed templates but when i finish next revbump it will be working for this l10n too. As per above I just expected portage to ignore the bump until it can get proper depgraph.
(In reply to comment #1) > Hmm I thought portage will just ignore the update... If we want to avoid the blocker in comment #0, we to know how the conflicting packages got pulled into the graph. Usually the blocker display includes that information, and emerge --tree output often helps as well. > Could this depstring solve it instead those blockers? > > || ( > >=app-office/libreoffice-3.4.4.2-r1 > >=app-office/libreoffice-bin-3.4.3.2-r1 > ) Maybe. Normally emerge pulls in the latest version automatically, so that leads me to suspect that the user has the new version masked or something like that. The output of `emerge -p '>=app-office/libreoffice-3.4.4.2-r1'` might provide a clue about why the update didn't get pulled in automatically. (In reply to comment #2) > As per above I just expected portage to ignore the bump until it can get proper > depgraph. What bump are you referring to? As said, I suspect the problem is that >=app-office/libreoffice-3.4.4.2-r1 is masked for some reason.
(In reply to comment #3) > What bump are you referring to? I guess it's the libreoffice-l10n-3.4.4-r1 version bump? The thing is, both libreoffice-l10n-3.4.4-r1 and libreoffice-3.4.4.2-r1 have unstable keywords: http://packages.gentoo.org/package/app-office/libreoffice-l10n http://packages.gentoo.org/package/app-office/libreoffice So, maybe it's just that the user has package.accept_keywords settings for libreoffice-l10n but not for libreoffice, and those settings need to be updated to match?
(In reply to comment #4) > > So, maybe it's just that the user has package.accept_keywords settings for > libreoffice-l10n but not for libreoffice, and those settings need to be updated > to match? No my box is full ~amd64
(In reply to comment #5) > (In reply to comment #4) > > > > So, maybe it's just that the user has package.accept_keywords settings for > > libreoffice-l10n but not for libreoffice, and those settings need to be updated > > to match? > No my box is full ~amd64 So, did you sync before the libreoffice-3.4.4.2-r1 update became available, or what? In other words, does `emerge -p '>=app-office/libreoffice-3.4.4.2-r1'` report that it's masked or unavailable?
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > > > > So, maybe it's just that the user has package.accept_keywords settings for > > > libreoffice-l10n but not for libreoffice, and those settings need to be updated > > > to match? > > No my box is full ~amd64 > > So, did you sync before the libreoffice-3.4.4.2-r1 update became available, or > what? In other words, does `emerge -p '>=app-office/libreoffice-3.4.4.2-r1'` > report that it's masked or unavailable? My cvs tree is fully updated laptop dev # emerge -p =app-office/libreoffice-3.4.4.2-r1 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] app-office/libreoffice-3.4.4.2-r1 [ebuild N ] virtual/ooo-0 [ebuild N ] app-office/libreoffice-l10n-3.4.4-r1 USE="-offlinehelp -templa tes" LINGUAS="el en -af -ar -as -ast -be -bg -bn -bo -br -brx -bs -ca -ca_XV -cs -cy -da -de -dgo -dz -en_GB -en_ZA -eo -es -et -eu -fa -fi -fr -ga -gd -gl -gu -he -hi -hr -hu -id -is -it -ja -ka -kk -km -kn -ko -kok -ks -ku -lo -lt -lv -ma i -mk -ml -mn -mni -mr -my -nb -ne -nl -nn -nr -nso -oc -om -or -pa_IN -pl -pt - pt_BR -ro -ru -rw -sa_IN -sat -sd -sh -si -sk -sl -sq -sr -ss -st -sv -sw_TZ -ta -te -tg -th -tn -tr -ts -ug -uk -uz -ve -vi -xh -zh_CN -zh_TW -zu" [blocks B ] <=app-office/libreoffice-3.4.4.2-r1 ("<=app-office/libreoffice- 3.4.4.2-r1" is blocking app-office/libreoffice-l10n-3.4.4-r1) I fail to understand what is the root of the problem so I can provide more sane output. 3.4.4.2-r1 is the latest (unmasked) version of libreoffice I have in my cvs tree
(In reply to comment #7) > [blocks B ] <=app-office/libreoffice-3.4.4.2-r1 > ("<=app-office/libreoffice- > 3.4.4.2-r1" is blocking app-office/libreoffice-l10n-3.4.4-r1) I misread the blocker. I wat thinking it was a < operator instead of a <= blocker. (In reply to comment #2) > As per above I just expected portage to ignore the bump until it can get proper > depgraph. We could backtrack and suppress the update in this case, but it should at least trigger a warning, since users generally do not want to miss updates. In essence, the "we're just waiting for a version bump" case is not distinguishable from the "we've got blockers that need to be resolved before this update can proceed" case.
(In reply to comment #8) > In essence, the "we're just waiting for a version bump" case is not > distinguishable from the "we've got blockers that need to be resolved before > this update can proceed" case. Well fair point but shouldn't the maintainer take care of that and not add this blocker before adding the newer version to portage?
(In reply to comment #1) > Could this depstring solve it instead those blockers? > > || ( > >=app-office/libreoffice-3.4.4.2-r1 > >=app-office/libreoffice-bin-3.4.3.2-r1 > ) Now I see what you mean. Yes, that would be the correct approach. Incidentally, it would also trigger a DEPEND.bad repoman error, since those dependencies would be unsatisfied until you add those ebuilds to the tree. (In reply to comment #9) > (In reply to comment #8) > > In essence, the "we're just waiting for a version bump" case is not > > distinguishable from the "we've got blockers that need to be resolved before > > this update can proceed" case. > > Well fair point but shouldn't the maintainer take care of that and not add this > blocker before adding the newer version to portage? Right. In essence, we have a DEPEND.bad that's being hidden by the fact that a blocker was used instead of a normal positive dependency.
*** Bug 390289 has been marked as a duplicate of this bug. ***
I have the same problem with libreoffice-bin, which I guess should be solved with the depstring change. Any idea when that will hit the portage tree? (also, I used to have openoffice-bin, which eventually got wrapped into ooo, but I'm unsure how I would now get libreoffice to compile instead of libreoffice-bin, since ooo doesn't have compile flags and ooo isn't part of eselect. What am I missing?)
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > In essence, the "we're just waiting for a version bump" case is not > > > distinguishable from the "we've got blockers that need to be resolved before > > > this update can proceed" case. > > > > Well fair point but shouldn't the maintainer take care of that and not add this > > blocker before adding the newer version to portage? > > Right. In essence, we have a DEPEND.bad that's being hidden by the fact that a > blocker was used instead of a normal positive dependency. As a temporary fix, I've removed all KEYWORDS from libreoffice-l10n-3.4.4-r1.ebuild.
+ 12 Nov 2011; Lars Wendler <polynomial-c@gentoo.org> + libreoffice-l10n-3.4.4-r1.ebuild, libreoffice-l10n-9999-r1.ebuild: + non-maintainer commit: Fixed dependency on libreoffice{,-bin} packages (bug + #390271). Changes added with kind permission from scarabeus. +
*** Bug 390313 has been marked as a duplicate of this bug. ***
*** Bug 390353 has been marked as a duplicate of this bug. ***
!<=app-office/libreoffice-3.4.4.2-r1 and !<=app-office/libreoffice-bin-3.4.4.2-r1 should be rather transformed into: || ( >app-office/libreoffice-3.4.4.2-r1 >app-office/libreoffice-bin-3.4.4.2-r1 ) Or: || ( >=app-office/libreoffice-3.4.4.2-r2 >=app-office/libreoffice-bin-3.4.4.2-r2 )
IMHO the best change would be this in the libreoffice-bin-3.4.3.2-r1.ebuild : PDEPEND=" - >=app-office/libreoffice-l10n-$(get_version_component_range 1-2) + =app-office/libreoffice-l10n-$(get_version_component_range 1-2)* " this provides only the right version and not higher untested stuff. works for me now: echo "=app-office/libreoffice-l10n-3.4.4-r1" >> /etc/portage/package.mask (Timestamp of tree: Sun, 13 Nov 2011 17:30:02 +0000)
sorry, I meant this: echo "=app-office/libreoffice-l10n-3.4.4*" >> /etc/portage/package.mask
sorry again, this is correct PDEPEND=" - >=app-office/libreoffice-l10n-$(get_version_component_range 1-2) + =app-office/libreoffice-l10n-$(get_version_component_range 1-3)* " if applied consequently in all libreoffice-bin ebuilds this could prevent future collisions.