Bugzilla Bug 24391

The ebuilds for realplayer aren't doing fetch restriction properly.  See bug
#10347 and bug #24296 for details about this.  I'll attach a patch to the
realplayer-8-r5 momentarily which fixes the problem.  Another nice side-effect
of this is that Portage can actually store digests of the realplayer files, too.
 Because of the way the ebuild is structured, that means there's a few extra
steps to create the digest.

The ebuild currently sets ${A} based on which arch is selected.  In my ebuild
(about to be attached), SRC_URI looks like this:

SRC_URI="x86? http://docs.real.com/docs/playerpatch/unix/rv9_libc6_i386_cs2.tgz
        ${A}"

If you try and generate a digest from this SRC_URI, you'll only get a digest
which includes the arch you're running the digest on.  So, in order to correctly
generate a digest, you'll have to change SRC_URI to look like this before
generating the digest:

SRC_URI="x86? http://docs.real.com/docs/playerpatch/unix/rv9_libc6_i386_cs2.tgz
    rp8_linux20_libc6_i386_cs2.bin
    rp8_linux_powerpc_cs1.bin
    rp8_linux_sparc_cs1.bin
    rp8_linux_alpha_rh62_cs1.bin"

It's an extra step, yes, but I think the benefits far outweigh the downsides. 
I'll attach the digest file as well.

Reproducible: Always
Steps to Reproduce:

Created an attachment (id=14433) [edit]
realplayer-8-r6.ebuild.diff

Here's a patch to include proper fetch restriction handling.

Created an attachment (id=14434) [edit]
digest-realplayer-8-r6

Here's the complete digest file.

Created an attachment (id=14435) [edit]
realplayer-8-r6.ebuild

And, just for good measure, here's the ebuild itself (not a diff)

Come to think of it, before this is checked in, it would probably be a good
idea to put some text in the ebuild descbing how to properly re-generate the
digest file.  Otherwise someone could end up checking in a digest file which
only contained one arch in it...

actually, the extra steps are not necessary on a dev box, because devs have
"cvs" in FEATURES.

fetch restriction not turned on, because there is ONE file to fetched for at
least x86.

Please rsync and recheck (no revision bump, so still -r5)

Whoa, heh, yeah, neglected to notice that one file that *can* be downloaded. 
Thanks!