[gentoo-user] Re: useflag hell.

[Kai Krakow]

Am Sun, 28 Feb 2016 21:01:48 +0200
schrieb Alan McKinnon <alan.mckinnon@×××××.com>:

> On 28/02/2016 20:14, Alan Grimes wrote:
> > I've been running number theory code for a few weeks, so haven't
> > been updating my machine too often...
> >
> > I for the last day or so I'm in a run my "pretendupdate" script,
> > look at the results, decide whether to run ufed or bleep with
> > package.use.... run the pretendupdate script again, do something
> > while it computes, come back to it hours later, and repeat the
> > cycle... This is really getting silly and I'm starting to suspect
> > that I'm stuck in useflag hell and there isn't a solution to this.
>
>
> There's always a solution, and they are seldom hard to solve. However,
> portage doesn't exactly make it easy for you with the output. Mere
> information is often obfuscated and looks like stuff you must fix,
> whereas the real nuggets can be hidden in the noise.
>
> Often running without -v can help considerably.
>
> So, here goes, comments inline
> >
> >
> >
> >
> > tortoise ~ # ./pretendupdate
> >
> > These are the packages that would be merged, in order:
> >
> > Calculating dependencies... done!
> >
> > !!! Multiple package instances within a single package slot have
> > been pulled !!! into the dependency graph, resulting in a slot
> > conflict:
> >
> > dev-libs/icu:0
> >
> >   (dev-libs/icu-56.1:0/56::gentoo, ebuild scheduled for merge)
> > pulled in by (no parents that aren't satisfied by other packages in
> > this slot)
> >
> >   (dev-libs/icu-55.1:0/55::gentoo, installed) pulled in by
> >     dev-libs/icu:0/55=[abi_x86_32(-),abi_x86_64(-)] required by
> > (dev-qt/qtcore-4.8.7-r1:4/4::gentoo, installed)
> >
> > ^^^^^^
>
> Despite what it looks like all this is mere information.
> Two separate things result in different version of Qt being pulled
> into the problem solution. And it's exactly the form you'd expect.
>
> The first chunk is really saying that icu-56.1 is the most recent
> version and all other things being equal, that's the one portage would
> install. The second chunk is saying that qtcore-4.8.7-r1 requires
> icu-55.1 (not the most recent), so portage spews forth heaps of junk
> to helpfully let you not figure it out.
>
> What portage really should say is more like:
>
> Most recent version of icu (icu-56.1) not installed due to these
> requirements:
> qtcore-4.8.7-r1 requires icu-55.1
>
> Ignore the multiple OMG! bangs before all of the above output
>
>
> >
> >
> >
> > 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.
> >
> >
> > !!! The ebuild selected to satisfy
> > ">=media-libs/mlt-0.9.8-r1[ffmpeg,kdenlive,melt,qt5,sdl,xml]" has
> > unmet requirements.
>
> This is the expression portage needs to install based on dependencies,
> most recent version, maskings, and your USE flags. It's informational.
>
> > - media-libs/mlt-0.9.8-r2::gentoo USE="ffmpeg fftw gtk kde kdenlive
> > lua melt opengl python qt5 sdl xine xml -compressed-lumas -debug
> > -frei0r -jack -libav -libsamplerate -qt4 -rtaudio (-ruby) -vdpau"
> > ABI_X86="64" CPU_FLAGS_X86="mmx sse sse2" PYTHON_TARGETS="python2_7"
> >
> >   The following REQUIRED_USE flag constraints are unsatisfied:
> >     kde? ( qt4 )
>
> This is the actual problem, According to the ebuild, if you set
> USE="kde", then you also need USE="qt4". Your USE has qt5 enabled, and
> that's the problem.
>
> Presumably, mtl does not yet support KDE with Qt5
> >
> >   The above constraints are a subset of the following complete
> > expression: python? ( python_targets_python2_7 ) qt5? ( !qt4 ) kde?
> > ( qt4 )
>
> And this is the helpful gigantic USE expression, all of which must be
> satisfied to install mlt. The bit above this shows just the part that
> is problematic, so this is also informational. Note
> >
> > (dependency required by
> > "kde-apps/kdenlive-15.12.1::gentoo" [ebuild]) (dependency required
> > by "kde-apps/kdemultimedia-meta-15.12.1-r1::gentoo" [ebuild])
> > (dependency required by "kde-apps/kde-apps-meta-15.08.3-r3::gentoo"
> > [ebuild])
> > (dependency required by
> > "kde-apps/kde-meta-15.08.3::gentoo" [ebuild]) (dependency required
> > by "@selected" [set]) (dependency required by "@world" [argument])
>
> And the is a part of the full dep tree that leads to mlt being
> included
> > tortoise ~ #
> >
> >
> > ######################
> >
> >
> > The attached files are whatever is left after --- six years of
> > resolving similar issues on this same install...
>
>
> What you need to do now is set one of the following combinations in
> package.use for mlt:
>
> USE=-kde qt4 -qt5
> USE=kde qt4 -qt5
>
> On a plasma system like you have this will probably cause similar
> issues for other packages, so you must iteratively solve those as
> well till no more inconsistencies remain.
>
> Portage does an atrocious job of presenting it's output to you, but
> essentially it's a problem in graph theory and detecting mutually
> incompatible data.

Well, I fixed it by simply not enabling USE="kde" for those packages.
Plasma is not really the old KDE suite, so disabling kde in favor of
qt5 will make it work better with plasma software.

This also solves a dependency hell with qtcurve: Disabling kde allows
to enable qt4 which takes care of properly supporting old KDE4
software.

You actually probably don't want software to hook into the old KDE4
software suite as you are configuring KDE specifica through plasma.
Most software will still properly work just by enabling qt4.

In case of problems I suggest to first set USE="-kde", if it does not
work, USE="-kde -qt4".

I use mlt[-kde,qt4] and it still works for KDE software like kdenlive.

It was the most easy fix to just disable those useflags when dep
problems occurred - without getting a myriad of follow-up dep problems.
And all features still work as expected.

I expect that USE=kde will probably fade away anyway during migration
to plasma - and with it dies USE=qt4. So turning these both use flags
off in that order gets you out of most of the trouble easily.

-- 
Regards,
Kai

Replies to list-only preferred.