I have run across this problem once again, and I find it incredibly frustrating. The Sun Java packages (including dev-java/java-sdk-docs) require you to manually go out and download their source packages. This is totally fine, but when I do an "emerge -f" on a bunch of ebuilds, I would expect a message to be thrown at that point. Very often I start off a bunch of things emerging overnight (when I know I won't be at the computer), but before I leave I do an emerge -f to ensure that everything's downloaded properly. Then I go home confident that when I come back in the morning I'll have everyhing I need. However, if a Java package happens to be in the list (due to dependencies - I usually remember to download it by hand if I'm downloading Java explicitly), I invariably come back in the morning (like this morning) to discover that the whole process came to a screeching halt less than an hour after I started everything out, because I have to go manually download the Java packages. I believe this happens in a few other ebuilds as well, but I can't think of what they are off the top of my head. At any rate, it's my belief that "emerge -f" should *really* be responsible for letting the user know that there are some files that need to be downloaded by hand. I'll try an cobble together a patch to that effect later, but I just wanted to get this into the system first... Apologies if I seem testy. Reproducible: Always Steps to Reproduce: 1. Select a bunch of packages to install which include dependencies which would install java-sdk-docs or sun-j2sdk or the like 2. Run "emerge -f" on these packages Actual Results: emerge -f will download anything necessary EXCEPT for the Java packages, and then tell you that everything has been downloaded successfully. Expected Results: emerge -f should have let me know which packages require a manual download.
portage bug ?
Perhaps if there was something like a pkg_fetch() hook (I tried using the pkg_nofetch() mentioned in the Ebuild docs, but it doesn't seem to do what I was thinking here) which would be called during the "fetch" target (so it would be called on "emerge -f"), and this function could include the code found in the ebuild: if [ ! -f ${DISTDIR}/${At} ] ; then die "Please download ${At} from ${HOMEPAGE} and move it to ${DISTDIR}" fi If someone were just emerging normally, things would still function as you'd expect them to...
Heh. Too funny. pkg_nofetch is something I had actually contributed before... See bug #10347. Hurray for long-term memory, no? Okay, I can submit a patch to java-sdk-docs in just a second or two that should function properly.
Created attachment 14378 [details, diff] java-sdk-docs-1.4.1-r1.diff Yeah, this is basically exactly what I was looking for, which does make this a bug with the ebuild, not with portage in general. Essentially, you just put in the filename for SRC_URI, then add RESTRICT="fetch" and some text in a pkg_nofetch() function, and everything works fine. An added benefit for doing this is that now you can actually have a digest file for these files as well, because Portage knows the file on account of the SRC_URI.
Created attachment 14379 [details, diff] java-sdk-docs-1.3.1-r1.diff Here's a diff for java-sdk-docs-1.3.1 as well. Other packages from java.sun.com should probably be modified in a similar fashion. I'd be happy to submit the necessary patches if you'd like, but I'll hold off in case whoever ends up submitting these would rather just do it yourself and not be bothered with a bunch more emails from bugzilla. Let me know and I'll code 'em up though.
I have made changes on sun-jdk's ebuilds, next step is to change it on java-sdk-docs. I have not commited them to portage cause im also upgrading JDK.
Commited to portage tree.
It seems as though this fix didn't get entirely updated for java-sdk-docs-1.4.2... RESTRICT="fetch" is in the ebuild, but SRC_URI is left blank, so the fetch restriction still doesn't work quite right. Also, the package checking in "src_unpack" should really be moved to "pkg_nofetch" similar to what's in place for the sun-jdk ebuilds. Thanks!
This was fixed but java-sdk-docs-1.4.2 was added later without the fix
This should be fixed now on portage tree.