Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 390271 - emerge -uDNav world breaks due to weird libreoffice blockers
Summary: emerge -uDNav world breaks due to weird libreoffice blockers
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Office Team
URL:
Whiteboard:
Keywords:
: 390289 390313 390353 (view as bug list)
Depends on:
Blocks: 390437
  Show dependency tree
 
Reported: 2011-11-12 16:06 UTC by Markos Chandras (RETIRED)
Modified: 2011-11-13 18:49 UTC (History)
9 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markos Chandras (RETIRED) gentoo-dev 2011-11-12 16:06:49 UTC
[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
Comment 1 Tomáš Chvátal (RETIRED) gentoo-dev 2011-11-12 16:21:39 UTC
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
    )
Comment 2 Tomáš Chvátal (RETIRED) gentoo-dev 2011-11-12 16:23:09 UTC
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.
Comment 3 Zac Medico gentoo-dev 2011-11-12 16:37:18 UTC
(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.
Comment 4 Zac Medico gentoo-dev 2011-11-12 17:34:33 UTC
(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?
Comment 5 Markos Chandras (RETIRED) gentoo-dev 2011-11-12 17:55:08 UTC
(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
Comment 6 Zac Medico gentoo-dev 2011-11-12 18:00:50 UTC
(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?
Comment 7 Markos Chandras (RETIRED) gentoo-dev 2011-11-12 18:06:52 UTC
(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
Comment 8 Zac Medico gentoo-dev 2011-11-12 18:12:12 UTC
(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.
Comment 9 Markos Chandras (RETIRED) gentoo-dev 2011-11-12 18:14:10 UTC
(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?
Comment 10 Zac Medico gentoo-dev 2011-11-12 18:16:28 UTC
(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.
Comment 11 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2011-11-12 19:34:29 UTC
*** Bug 390289 has been marked as a duplicate of this bug. ***
Comment 12 movrev 2011-11-12 21:17:25 UTC
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?)
Comment 13 Zac Medico gentoo-dev 2011-11-12 21:28:30 UTC
(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.
Comment 14 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2011-11-12 21:43:03 UTC
+  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.
+
Comment 15 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2011-11-12 22:26:08 UTC
*** Bug 390313 has been marked as a duplicate of this bug. ***
Comment 16 Tomáš Chvátal (RETIRED) gentoo-dev 2011-11-13 10:19:57 UTC
*** Bug 390353 has been marked as a duplicate of this bug. ***
Comment 17 Arfrever Frehtes Taifersar Arahesis 2011-11-13 17:22:50 UTC
!<=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
)
Comment 18 Philipp Psurek 2011-11-13 18:14:38 UTC
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)
Comment 19 Philipp Psurek 2011-11-13 18:16:29 UTC
sorry, I meant this:
echo "=app-office/libreoffice-l10n-3.4.4*" >> /etc/portage/package.mask
Comment 20 Philipp Psurek 2011-11-13 18:31:22 UTC
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.