Summary: | PORTAGE_BINHOST stale metadata triggers unsatisfied deps | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Gokdeniz Karadag <gokdenizk> |
Component: | Binary packages support | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 194552 | ||
Bug Blocks: | |||
Attachments: | emerge commands run on the client |
Description
Gokdeniz Karadag
2007-11-17 02:37:30 UTC
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" |