Bug 56381 – Specifying a HTTP redirect as an ebuild's SRC_URI breaks emerge

• Product: Gentoo Linux
• Status: RESOLVED WORKSFORME

[Description Keith Lea 2004-07-07 14:59:20 UTC]

I'm trying to write an ebuild for IntelliJ IDEA (EAP release). The download URL's look like this though: http://www.intellij.net/eap/products/idea/redirect.jsp?filename=idea2174.tar.gz and this redirects to an Akamai server which actually serves the file.

My problem is that wget stores the file as "idea2174.tar.gz" and no matter what I try I can't get emerge to realize that the filename isn't "redirect.jsp?filename=idea2174.tar.gz", so I can't get the ebuild to work without manually md5summing and unpacking.

I think emerge should be smarter about which files wget downloads.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

[Comment 1 Chris White (RETIRED) 2004-07-07 15:09:57 UTC]

Actually, this is what we call a fetchonly ebuild.  A fetchonly ebuild is when
whoever created the package the ebuild is based on does not want the source
downloaded directly.

This normally happens when the site wants you to signup for an account in order
to download the file (in this case) or agree to a special license
(java-sdk-docs).

For example of fetchonly restriction, check the java-sdk-docs ebuilds.
You can also check the gentoo.org docs and man 5 ebuild.

If this seems like what you're looking for, please close the bug.

[Comment 2 Jeremy Huddleston (RETIRED) 2004-07-07 15:16:06 UTC]

closing...

[Comment 3 Keith Lea 2004-07-07 17:16:11 UTC]

Fetchonly would solve this problem, but it's overkill. It's silly to make the user visit the website just to get past an HTTP redirect. 

Typing 'wget http://www.intellij.net/eap/products/idea/redirect.jsp?filename=idea2174.tar.gz' DOES download the file, the only problem is that emerge assumes the filename is "redirect.jsp?filename=idea2174.tar.gz", when in fact it's idea2174.tar.gz.

This bug is still valid: emerge should be smarter about what file was saved by the downloading application.

[Comment 4 SpanKY 2004-07-07 17:47:14 UTC]

why not use the actual URL in SRC_URI that you are redirected to

[Comment 5 Keith Lea 2004-07-07 18:45:39 UTC]

The URL is randomly selected from IntelliJ's Akamai servers, and it changes each time. Often, a redirected URL is valid when it's created (by visiting redirect.jsp) but is not valid a few minutes later (after the server has assumed that you followed the redirect).

[Comment 6 Nicholas Jones (RETIRED) 2004-07-08 14:44:17 UTC]

Is there a reason you don't just mirror it yourself (mirror://)?
If the answer is yes, then fetch restrict it.

[Comment 7 Keith Lea 2004-07-08 19:23:27 UTC]

I don't have a reliable place to host a mirror, and also, new builds are released every few days, and I wouldn't have time to keep the mirror updated with new builds.

I don't think this bug should be marked invalid or worksforme, I think it's a real problem with emerge and the ebuild format, and should be left open, even if there are no current plans to fix it.

[Comment 8 Jeremy Huddleston (RETIRED) 2004-07-09 04:30:17 UTC]

Keith, download it yourself and put RESTRICT="fetch" in the ebuild.  YOU don't host the mirror.  It's put on the gentoo mirror if your ebuild is ever accepted intpo portage... if youu keep it private, then this whole discussion is moot.

[Comment 9 Keith Lea 2004-07-09 05:46:12 UTC]

I'm saying that you shouldn't have to restrict=fetch for a simple "Location:" HTTP redirect. I don't know how mirroring works for ebuilds, I've never done that, but as far as I can tell, it doesn't solve this problem.