Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 199413

Summary: PORTAGE_BINHOST stale metadata triggers unsatisfied deps
Product: Portage Development Reporter: Gokdeniz Karadag <gokdenizk>
Component: Binary packages supportAssignee: 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
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
Comment 1 Gokdeniz Karadag 2007-11-17 02:39:01 UTC
Created attachment 136127 [details]
emerge commands run on the client
Comment 2 Gokdeniz Karadag 2007-11-17 02:42:56 UTC
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.
Comment 3 Zac Medico gentoo-dev 2007-11-17 11:07:44 UTC
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).
Comment 4 Gokdeniz Karadag 2007-11-17 13:02:31 UTC
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 :)
Comment 5 Zac Medico gentoo-dev 2007-11-17 18:36:00 UTC
(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.
Comment 6 Gokdeniz Karadag 2007-11-18 11:57:31 UTC
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])

Comment 7 Zac Medico gentoo-dev 2007-11-18 20:44:19 UTC
(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.
Comment 8 Gokdeniz Karadag 2007-11-18 21:25:29 UTC
Ok, it used the updated dependencies this time. Digikam is installed and working fine, thank you.
Comment 9 Zac Medico gentoo-dev 2007-11-18 21:56:39 UTC
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).
Comment 10 Gokdeniz Karadag 2009-04-10 17:00:31 UTC
(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"