I would email, but dev.gentoo.org smtpd still doesn't like me... I tried to perform `ebuild kpdf-3.4.0_beta1.ebuild digest` which resulted in >>> Generating digest file... <<< kdegraphics-3.3.90.tar.bz2 !!! We have a source URI, but no file... !!! File: /usr/portage/distfiles/kdegraphics-3.3.90.tar.bz2 today and was pretty surprised by the tarball version and that it not even tried to fetch it... Exposing a few variables revealed the follwing: *** $PV: 3.4.0_beta1 *** *** $myPV: kdegraphics-3.3.91 *** and after # Main tarball for normal downloading style │ case "$myPV" in │ 3.3.9?) SRC_PATH="unstable/${myPV}/src/${myPN}-${myPV}.tar.bz2" ;; │ 3.3.0) SRC_PATH="stable/3.3/src/${myP}.tar.bz2" ;; │ 3*) SRC_PATH="stable/${myPV}/src/${myP}.tar.bz2" ;; │ 5) SRC_URI="" # cvs ebuilds, no SRC_URI needed │ debug-print "$ECLASS: cvs detected, SRC_URI left empty" ;; │ *) die "$ECLASS: Error: unrecognized version ${myPV}, could not set SRC_URI" ;; │ esac *** $SRC_URI: *** Since I did not have a real look at this eclass, yet, I think I let you tinker with it. The eclass could be a bit more verbose in general from my POV.
It needs kdegraphics-3.3.90.tar.bz2 for the digest for xdelta mode to work. With USE=kdexdelta, it'll download the 3.3.90 (alpha1) tarball and the (official upstream) 3.3.90-3.3.91 xdelta and apply it at unpacking time. This useflag is off by default, so usually you just see that in the digests... So the behaviour is OK AFAICS. As for not fetching on digest, I don't know why that'd happen (doesn't happen here), but it's surely a portage issue not a kde one... Check the SRC_URI in the cache to be sure.
Not fetching on digest is behavior/bug with portage 2.0.51 (or at least this was reported to me on irc). This is also reported in bug #69462
So as per my first comment, the eclass is OK and the bug is due to portage.
