qt-script, qt-core, qt-sdl, qt-dbus, qt-gui slot conflict

uvok · n00b Joined: 14 Oct 2008 Posts: 26

There seems to be a slot conflict for some qt-packages:

MaDxRaY · Posted: Thu Feb 12, 2009 12:46 pm Post subject:

I think the reason is the ebuild structure, as almost every qt* ebuild has rdepends which are fixed to the ebuilds own version. As qt is still 4.4.2 it requires qt-script-4.4.2 which has rdepends... think recursive ;-)

I'll check if qt-4.4.2 will run with qt-scripts-4.5.0_rc1 and make a patched qt ebuild.

Maybe qt-4.5.0* will be in portage soon and any effort is useless but I'ld like to have a clean merged system ;-)

_________________
greetz
Ray

yngwin · Posted: Thu Feb 12, 2009 2:29 pm Post subject:

You need to unmerge the x11-libs/qt-4.4.2 meta ebuild. 4.5.0_rc1 does not have a meta ebuild (and nothing in portage should depend on it). You may also need to fix your /var/lib/portage/world file if it has a naked x11-libs/qt because of Qt3, which should say x11-libs/qt:3 in your world file.
After that, the upgrade to split Qt 4.5.0_rc1 ebuilds should be fine.
_________________
"Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF

MaDxRaY · Posted: Thu Feb 12, 2009 2:39 pm Post subject:

paladin-zero · Guru Joined: 19 May 2004 Posts: 322

There are still some packages that depend on x11-libs/qt:

MaDxRaY · Posted: Thu Feb 12, 2009 3:59 pm Post subject:

Hwoarang · Posted: Thu Feb 12, 2009 4:00 pm Post subject:

@paladin-zero

No this is not true

All of them depend either on qt:4 or split ebuilds

I ll give some examples

qca-2.0.1-r1

platojones · Posted: Thu Feb 12, 2009 4:12 pm Post subject:

Wow, I'm getting nowhere fast in upgrading to the qt-4.5 ebuilds. I can't figure out what is pulling the qt-4.4.2 ebuilds in. I don't have the qt-4.4.2 meta installed and have removed all of the qt packages from my system, yet still it wants to pull in the qt-4.4.2 stuff along with the qt-4.5 stuff...can anybody tell from this why qt-4.4.2 is getting pulled in?

Hwoarang · Posted: Thu Feb 12, 2009 4:15 pm Post subject:

Using -t parameter on emerge -uDNavt world will show us why this is happening

platojones · Posted: Thu Feb 12, 2009 4:23 pm Post subject:

Hwoarang · Posted: Thu Feb 12, 2009 4:27 pm Post subject:

Thats weird. Both of them dont have strict qt-4.4.2 dependencies. Could you unemerge both and then try to re-emerge them agian?

That would have been really helpfull

platojones · Posted: Thu Feb 12, 2009 4:30 pm Post subject:

telperion · n00b Joined: 07 Jan 2008 Posts: 3

https://bugs.gentoo.org/show_bug.cgi?id=258712#c5

paladin-zero · Guru Joined: 19 May 2004 Posts: 322

platojones · Posted: Thu Feb 12, 2009 5:04 pm Post subject:

Hwoarang · Posted: Thu Feb 12, 2009 5:08 pm Post subject:

@paladin-zero

As I said before

run emerge -uDNavt world. Make sure to have -t parameter

You will have enough information to figure out what is going on

Make sure that you have keyworded all the qt-modules otherwise you will end up with conflits

paladin-zero · Guru Joined: 19 May 2004 Posts: 322

I just tried remerging cmake, qca, qimageblitz and avahi. Then I ran equery depends ">qt-4":

Hwoarang · Posted: Thu Feb 12, 2009 5:15 pm Post subject:

This output is not valid and show us nothing

try running equery depends qt-gui or qt-core and you will see what i mean

I ve asked again, but are all your qt-modules placed on /etc/portage/package.keywords file?

Also ready carefully yngwins post ( #3 ) and especially the part about world file

paladin-zero · Guru Joined: 19 May 2004 Posts: 322

Hwoarang · Posted: Thu Feb 12, 2009 5:21 pm Post subject:

paladin-zero · Guru Joined: 19 May 2004 Posts: 322

Hwoarang · Posted: Thu Feb 12, 2009 5:26 pm Post subject:

Thats because you are using wrong parameter on equery depends

paladin-zero · Guru Joined: 19 May 2004 Posts: 322

Hwoarang · Posted: Thu Feb 12, 2009 5:49 pm Post subject:

Ok i dont mind explain it to you a little bit

Some packages depend on qt:4 OR qt-gui:4 ( or qt-core:4 ) or what ever module

if you run equery depends qt ( that means packages that depend on metapackage ) the output missleading you
cause you assume that those packages DO DEPEND on metapackage but NOT on modules.

This is wrong conclusion since every package that DEPEND on qt:4 depend also on qt-{gui,core}:4

If you find a package that doesnt depend on modules but ONLY on qt:4 please report it to us

Do you understand now why I said that your output is not valid? Cause you misunderstood that output

emerald · Tux's lil' helper Joined: 31 Jul 2005 Posts: 113

Sorry to ask this, but is there any way to always have all qt pieces merged (e.g. for development) without adding every qt-* ebuild to the world file? A set doesn't yet exist, at least it's nowhere in portage (2.2_rc*) or in the tree. What's actually the point of dropping all the meta packages, it appears to me as a quite comfortable system (adding many packages to the world file means more and more trouble in the future; a few meta packages or sets which bring in all wanted stuff - ok, maybe a bit more, but i hardly care as long as i got everything i need ready - and whenever a split-package is dropped or added the change is incorporated via the meta package/set and emerge --depclean cleans out all unused stuff). The world file should, in my opinion, contain as few entries as possible, that way its much easier to keep the system up-to-date and clean without much unused stuff (even for people developing and installing a bunch of packages they need for development). To keep track of every piece of a split package by hand is really 'high maintenance' and easily leads to unexpected blockers and such because of 'forgotten' things listed in the world file.
If sets are the 'new way of life' then for every dropped meta package should a set be available already, not only 'for download somewhere' like kde at first (later on the meta packages were provided still).
Up till now i'm somewhat.... suspicious or uncomfortable with sets, i've tried the @revdep-rebuild set once but it didn't honor the exact installed packages but only the package name, so for vmware-modules it tried to install a newer, incompatible and blocking version, so that moment i dropped the set thingy and 'moved back' to revdep-rebuild, which did and still does its job correct, without such strangeness and unpredictable behaviour.
_________________
Knowledge is scary....

... running Gentoo Linux ...
... and Windows in a 'small corner'(C) - i.e. vmware -

...
System Profile

Don't open the Red Door !