Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 24274 - Java, etc, manual package downloads and emerge -f
Summary: Java, etc, manual package downloads and emerge -f
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Adrian Almenar
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-07-11 05:15 UTC by CJ Kucera
Modified: 2003-09-08 21:36 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
java-sdk-docs-1.4.1-r1.diff (java-sdk-docs-1.4.1-r1.diff,935 bytes, patch)
2003-07-11 08:58 UTC, CJ Kucera
Details | Diff
java-sdk-docs-1.3.1-r1.diff (java-sdk-docs-1.3.1-r1.diff,931 bytes, patch)
2003-07-11 09:01 UTC, CJ Kucera
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description CJ Kucera 2003-07-11 05:15:01 UTC
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.
Comment 1 Martin Holzer (RETIRED) gentoo-dev 2003-07-11 07:45:42 UTC
portage bug ?
Comment 2 CJ Kucera 2003-07-11 08:30:50 UTC
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...
Comment 3 CJ Kucera 2003-07-11 08:40:26 UTC
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.
Comment 4 CJ Kucera 2003-07-11 08:58:53 UTC
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.
Comment 5 CJ Kucera 2003-07-11 09:01:54 UTC
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.
Comment 6 Adrian Almenar 2003-07-28 22:27:52 UTC
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. 
Comment 7 Adrian Almenar 2003-08-08 15:58:25 UTC
Commited to portage tree. 
Comment 8 CJ Kucera 2003-08-25 10:32:01 UTC
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!
Comment 9 Adrian Almenar 2003-09-07 11:32:54 UTC
This was fixed but java-sdk-docs-1.4.2 was added later without the fix 
Comment 10 Adrian Almenar 2003-09-08 21:36:41 UTC
This should be fixed now on portage tree.