On Tue, Jan 20, 2009 at 12:11 AM, KH <gentoo-user@konstantinhansen.de> wrote:
Daniel Pielmeier schrieb:
> 2009/1/19 KH <gentoo-user@konstantinhansen.de>:
>
>> This link was great help for me. Told me everything and how to read the
>> blocker. So I did:
>>
>> #emerge -avC qt-4.3.3
>> #emerge -DuavN world (This installed qt-4.4.2)
>>
>> But now I do have a problem. When I run
>>
>> #emerge --depclean -av
>>
>> I receive the following output:
>> [snip]
>>
>>>>> These are the packages that would be unmerged:
>>>>>
>>  dev-db/sqlite
>>    selected: 2.8.16-r4
>>   protected: none
>>     omitted: 3.6.6.2
>>
>>  x11-libs/qt
>>    selected: 4.4.2
>>   protected: none
>>     omitted: 3.3.8b-r1
>>
>> [snip some other qt-split-packages]
>>
>> What did I miss? This results in an infinite circle of unmerging and
>> emerging.
>>
>>
>
> I don't think --with-bdeps will solve this issue as qt- packages are
> no build-time-dependencies they are needed at runtime too.
> Did the affected packages got installed by your previous emerge world
> command. My guess is that depclean wants to remove this packages
> because they are simply not needed by other packages. Did they really
> get pulled in when doing another world update after removing the
> packages?
>
> Maybe checking again your world file or the files in
> /etc/portage/package.* for something suspicious is a good idea here.
>
>

Hi,

yes I had the blocker when running emerge -DuavN world . I unmerged
qt-4.3* and ran emerge -DuavN world again. That brought in the qt-4.4.2.
Tho investigate further:

equery d x11-libs/qt
[ Searching for packages depending on x11-libs/qt... ]
app-crypt/pinentry-0.7.5 (qt3? x11-libs/qt:3)
app-text/poppler-bindings-0.8.7 (qt3? >=x11-libs/qt-3.3:3)
                               (qt4? >=x11-libs/qt-4.3:4)
media-video/vlc-0.9.8a (qt4? =x11-libs/qt-4.3*:4)
                      (skins? =x11-libs/qt-4.3*:4)
net-im/skype-2.0.0.63 (x86 & !qt-static? =x11-libs/qt-4.3*:4)

Those are still depending on qt-4.3* but non are depending on 4.4.2.

I will try an emerge -1av skype to learn what it will depend on afterwards.

kh

You seem to have missed the point of this upgrade. The qt packages were split, as the single qt package was huge, without good reason. The ideal sequence of events (as I understand it) was:
1. qt-4.3.3 and split packages given mutual exclusion depends.
2. All packages depending on qt-4.3.3 get updated to having an || dependency between qt-4.3.3 and the correct split components.
3. split components stabilized, and qt-4.3.3 simultaneously masked (thus, no blockages, everyone upgrades)
4. qt-4.4.2 kept around for backward compatibility/badly formed e-builds, but is only a virtual package (check it out, it only has dependencies)

Somehow, 2 didn't get finished, causing the masking in 3 to get dropped, hence the blocking.
Nothing should ever need to depend on qt-4.4, as only needed components should be pulled in.
Reference: http://bugs.gentoo.org/show_bug.cgi?id=248038

As has been pointed out, equery d is not a good indicator of dependency. Use emerge -pv --depclean <atom> for a real indication (equery does a grep of the ebuild file, emerge only reports active dependencies, which is what most people care about. I've been tempted to file a bug for a while, but this seems to be the accepted behavior).

Nick