I have a binhost and a client that uses binary packages. When I try to install digikam on the client 3 things happen 1. If I use ebuilds and no binpkgs, all is fine. media-gfx/digikam-0.9.2 will be installed with two deps; media-libs/libkexiv2-0.1.5 and media-libs/libkdcraw-0.1.1 2. If I give --getbinpkg, portage tries to use binary package for digikam and dependencies, but it tries to perform these downgrades x11-libs/qt-3.3.4-r8 [3.3.8-r4] media-libs/freetype-2.1.10-r3 [2.3.4-r2] 3. If i give --getbinpkgonly digikam and its two dependencies cannot be installed. emerge: there are no ebuilds to satisfy "=x11-libs/qt-3.3.8-r3". (dependency required by "media-libs/libkdcraw-0.1.1" [binary]) I have run fixpackages on both systems. On the binhost 'emerge -pe digikam' does not state any downgrades, and both systems have the following installed [I--] [ ] x11-libs/qt-3.3.8-r4 (3) [I--] [ ] media-libs/freetype-2.3.4-r2 (2) I have tried removing the binaries(digikam libkdcraw libkexiv2) on the binhost and generating them again with quickpkg. The output of some commands on the client is coming as attachments. Reproducible: Always Steps to Reproduce: 1. try to emerge digikam with binary packages 2. 3. Actual Results: there is an unsatisfied dependency if binary only. It tries to downgrade qt if only --getbinpkg used. Expected Results: It should install digikam and dependencies from binaries only, as they were created on a working system
Created attachment 136127 [details] emerge commands run on the client
One more thing, the binhost can unmerge digikam, and remerge it from the same binaries. I have unmerged one of the dependencies, libkdcraw and compiled it again but that binary did not install on the client either.
Here is a script that will copy *DEPEND from the ebuilds in the portage tree to your binary or installed packages: http://dev.gentoo.org/~zmedico/portage/branches/2.1/bin/vdb-tools.py Usage examples: ./vdb-tools.py --transfer --pkgtype=binary ./vdb-tools.py --transfer --pkgtype=installed Although this tool is useful for updating the dependencies of some packages, we are trying to move away from dependencies like the qt-3.3.x ones that are triggering the problem. The kde team is planning to replace problematic dependencies like those with SLOT dependencies soon (using EAPI 1).
Thank you for the script and the explanation. But I ran the script on both the binhost and the client, for both binary and installed packages, but it still requires the downgraded qt. I deleted binary packages on binhost, run the vdb-tools script again with both options, made packages again with quickpkg, but still no progress. I may have compiled the three and moved on, but I volunteer to be a test case for better portage binary support :)
(In reply to comment #4) > But I ran the script on both the binhost and the client, for both binary and > installed packages, but it still requires the downgraded qt. It sounds like you are mixing different versions of the portage tree. The script works best when every system has an identical version of the tree.
I have performed sync, update world, depclean, revdep-rebuild on both machines, then copied dependency info again, tested, deleted existing packages, repacked them, tested, copied dependencies again tested again. Still no progress. The debug output for emerge -Gvd libkdcraw follows. libkdcraw states only dcraw as dependency and inheritws kde. I looked into kde.eclass but didn't know where to look, there was not much reference to qt. If you can point me to more tests I can perform them. If this thing is not too relevant for portage, I can try using --nodeps or compile the packages and we can close the bug. ===================================================== $ emerge -Gvd libkdcraw myaction None myopts {'--usepkgonly': True, '--ask': True, '--getbinpkg': True, '--verbose': True, '--debug': True, '--getbinpkgonly': True, '--usepkg': True} These are the packages that would be merged, in order: Calculating dependencies Fetching binary packages info... Loaded metadata pickle. cache miss: '0' --- cache hit: '926' -- DONE! Parent: None Depstring: media-libs/libkdcraw Priority: soft Candidates: ['media-libs/libkdcraw'] binary: media-libs/libkdcraw-0.1.1 Parent: ('binary', '/', 'media-libs/libkdcraw-0.1.1', 'merge') Depstring: Priority: hard Candidates: [] Exiting... ('binary', '/', 'media-libs/libkdcraw-0.1.1', 'merge') Parent: ('binary', '/', 'media-libs/libkdcraw-0.1.1', 'merge') Depstring: media-gfx/dcraw >=kde-base/kdelibs-3.0 || ( =x11-libs/qt-3.3.8-r3 =x11-libs/qt-3.3.8-r2 =x11-libs/qt-3.3.8-r1 =x11-libs/qt-3.3.8 =x11-libs/qt-3.3.6-r5 =x11-libs/qt-3.3.6-r4 =x11-libs/qt-3.3.6-r3 =x11-libs/qt-3.3.6-r2 =x11-libs/qt-3.3.6-r1 =x11-libs/qt-3.3.6 =x11-libs/qt-3.3.5-r1 =x11-libs/qt-3.3.5 =x11-libs/qt-3.3.4-r9 =x11-libs/qt-3.3.4-r8 =x11-libs/qt-3.3.4-r7 =x11-libs/qt-3.3.4-r6 =x11-libs/qt-3.3.4-r5 =x11-libs/qt-3.3.4-r4 =x11-libs/qt-3.3.4-r3 =x11-libs/qt-3.3.4-r2 =x11-libs/qt-3.3.4-r1 =x11-libs/qt-3.3.4 =x11-libs/qt-3.3.3-r3 =x11-libs/qt-3.3.3-r2 =x11-libs/qt-3.3.3-r1 =x11-libs/qt-3.3.3 =x11-libs/qt-3.3.2 =x11-libs/qt-3.3.1-r2 =x11-libs/qt-3.3.1-r1 =x11-libs/qt-3.3.1 =x11-libs/qt-3.3.0-r1 =x11-libs/qt-3.3.0 =x11-libs/qt-3.2.3-r1 =x11-libs/qt-3.2.3 =x11-libs/qt-3.2.2-r1 =x11-libs/qt-3.2.2 =x11-libs/qt-3.2.1-r2 =x11-libs/qt-3.2.1-r1 =x11-libs/qt-3.2.1 =x11-libs/qt-3.2.0 =x11-libs/qt-3.1.2-r4 =x11-libs/qt-3.1.2-r3 =x11-libs/qt-3.1.2-r2 =x11-libs/qt-3.1.2-r1 =x11-libs/qt-3.1.2 =x11-libs/qt-3.1.1-r2 =x11-libs/qt-3.1.1-r1 =x11-libs/qt-3.1.1 =x11-libs/qt-3.1.0-r3 =x11-libs/qt-3.1.0-r2 =x11-libs/qt-3.1.0-r1 =x11-libs/qt-3.1.0 ) xinerama? ( x11-libs/libXinerama ) arts? ( kde-base/arts ) Priority: medium Candidates: ['>=kde-base/kdelibs-3.0', '=x11-libs/qt-3.3.8-r3', 'media-gfx/dcraw'] binary: kde-base/kdelibs-3.5.7-r3 emerge: there are no ebuilds to satisfy "=x11-libs/qt-3.3.8-r3". (dependency required by "media-libs/libkdcraw-0.1.1" [binary])
(In reply to comment #6) > Parent: ('binary', '/', 'media-libs/libkdcraw-0.1.1', 'merge') > Depstring: media-gfx/dcraw >=kde-base/kdelibs-3.0 || ( =x11-libs/qt-3.3.8-r3 > =x11-libs/qt-3.3.8-r2 =x11-libs/qt-3.3.8-r1 =x11-libs/qt-3.3.8 This binary package has an outdated dependency string that originates from QT3VERSIONS variable that's defined in /usr/portage/eclass/qt3.eclass. If you ran `vdb-tools --transfer --pkgtype=binary` on the binhost, it should have updated the dependency in the binary package to include the latest version of qt from QT3VERSIONS (qt-3.3.8-r4). The script relies on 2 things: 1) QT3VERSIONS in the eclass contains 3.3.8-r4 2) The tree contains a libkdcraw-0.1.1.ebuild to copy *DEPEND from If the above conditions are met, it seems like you have stale metadata in the client side cache. You can purge the metadata like this: rm -f /var/cache/edb/{metadata.idx.most_recent,remote_metadata.pickle} After that, the client will have to fetch the metadata again, and it should get the correct metadata if the script worked correctly on the server side.
Ok, it used the updated dependencies this time. Digikam is installed and working fine, thank you.
So, we've got 2 different problems in this bug: 1) qt3.eclass and the way it uses QT3VERSIONS produces dependencies do not work well for binary packages. This will hopefully be should be solved soon using EAPI 1 SLOT dependencies. 2) The client side staleness checks for PORTAGE_BINHOST metadata are insufficient. It's probably not worth any effort to try and integrate better staleness checks in the old protocol handler, so we should probably just rely on the new protocol for that (bug 194552).
(In reply to comment #9) > So, we've got 2 different problems in this bug: > > 1) qt3.eclass and the way it uses QT3VERSIONS produces dependencies do not work > well for binary packages. This will hopefully be should be solved soon using > EAPI 1 SLOT dependencies. > EAPI 1 is stable > 2) The client side staleness checks for PORTAGE_BINHOST metadata are > insufficient. It's probably not worth any effort to try and integrate better > staleness checks in the old protocol handler, so we should probably just rely > on the new protocol for that (bug 194552). > that bug is fixed, so marking as "worksforme"