Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 377305 - emerge should call wget --content-disposition
Summary: emerge should call wget --content-disposition
Status: RESOLVED DUPLICATE of bug 177863
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - External Interaction (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: PMS/EAPI
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-01 18:26 UTC by Martin Mokrejš
Modified: 2011-08-01 20:31 UTC (History)
0 users

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Mokrejš 2011-08-01 18:26:10 UTC
I have:

SRC_URI="https://cgwb.nci.nih.gov/cgi-bin/bambino?download_bambino_jar=core
     https://cgwb.nci.nih.gov/cgi-bin/bambino?download_bambino_jar=bundle"


If emerge would call wget with an extra --content-disposition it would save the downloaded data under a proper filename. Or give us some variable into which one can inject some evil arguments to be passed down to wget, please. ;)


From man page of wget:
<quote>
       --content-disposition
           If this is set to on, experimental (not fully-functional) support
           for "Content-Disposition" headers is enabled. This can currently
           result in extra round-trips to the server for a "HEAD" request, and
           is known to suffer from a few bugs, which is why it is not
           currently enabled by default.

           This option is useful for some file-downloading CGI programs that
           use "Content-Disposition" headers to describe what the name of a
           downloaded file should be.
</quote>

wget --no-check-certificate --content-disposition https://cgwb.nci.nih.gov/cgi-bin/bambino?download_bambino_jar=core

(writes to bambino_core_1.02.jar)

wget --no-check-certificate --content-disposition https://cgwb.nci.nih.gov/cgi-bin/bambino?download_bambino_jar=bundle

(writes to bambino_bundle_1.02.jar)
Comment 1 Zac Medico gentoo-dev 2011-08-01 18:58:26 UTC
Are you aware of SRC_URI arrows which have been supported since EAPI 2? For example:

EAPI=2
SRC_URI="https://cgwb.nci.nih.gov/cgi-bin/bambino?download_bambino_jar=core -> bambino_core_1.02.jar
https://cgwb.nci.nih.gov/cgi-bin/bambino?download_bambino_jar=bundle -> bambino_bundle_1.02.jar"
Comment 2 Martin Mokrejš 2011-08-01 19:11:58 UTC
No, did not know, thanks. ;-)
Comment 3 Zac Medico gentoo-dev 2011-08-01 19:40:07 UTC
(In reply to comment #2)
> No, did not know, thanks. ;-)

No problem. I guess we can consider this as a duplicate of bug 177863.

*** This bug has been marked as a duplicate of bug 177863 ***
Comment 4 Martin Mokrejš 2011-08-01 19:58:36 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > No, did not know, thanks. ;-)
> 
> No problem. I guess we can consider this as a duplicate of bug 177863.

Umm, I hoped you keep this bug open as a feature request. If the wget call would be improved then one would need not the "->" trick in many cases and thing would work out of the box. It is just one http(s) connection extra.

Anyways, I tend to object as the trick is not documented here anyways: ;)
http://devmanual.gentoo.org/ebuild-writing/variables/index.html#src_uri
Comment 5 Ciaran McCreesh 2011-08-01 20:07:11 UTC
I don't think we should. Fetching is enough of a mess already without adding convolutions for silly upstreams, especially since arrows solve the problem.
Comment 6 Zac Medico gentoo-dev 2011-08-01 20:08:36 UTC
(In reply to comment #4)
> Umm, I hoped you keep this bug open as a feature request. If the wget call
> would be improved then one would need not the "->" trick in many cases and
> thing would work out of the box. It is just one http(s) connection extra.

I see a couple of problems with this approach:

1) Unlike SRC_URI arrows, the local filename cannot be derived from the SRC_URI metadata in a simple way. This is a problem since both the ebuild code and the package manager need this filename to be precisely defined.

2) If behavior of a remote server determines the local filename, then the filename is somewhat difficult to predict. It requires some sort of IPC between the fetcher program (wget) and the package manager, in order to communicate the local filename.

> Anyways, I tend to object as the trick is not documented here anyways: ;)
> http://devmanual.gentoo.org/ebuild-writing/variables/index.html#src_uri

You can file a new bug for that and assign to qa@gentoo.org.
Comment 7 Martin Mokrejš 2011-08-01 20:30:15 UTC
(In reply to comment #6)
> 2) If behavior of a remote server determines the local filename, then the
> filename is somewhat difficult to predict. It requires some sort of IPC between
> the fetcher program (wget) and the package manager, in order to communicate the
> local filename.

Parse the wget output?

$ wget --no-check-certificate --content-disposition https://cgwb.nci.nih.gov/cgi-bin/bambino?download_bambino_jar=core
--2011-08-01 22:21:41--  https://cgwb.nci.nih.gov/cgi-bin/bambino?download_bambino_jar=core
Resolving cgwb.nci.nih.gov... 137.187.182.38
Connecting to cgwb.nci.nih.gov|137.187.182.38|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 595652 (582K) [application/zip]
--2011-08-01 22:21:49--  https://cgwb.nci.nih.gov/cgi-bin/bambino?download_bambino_jar=core
Reusing existing connection to cgwb.nci.nih.gov:443.
HTTP request sent, awaiting response... 200 OK
Length: 595652 (582K) [application/zip]
Saving to: `bambino_core_1.02.jar'

100%[======================================>] 595,652     21.7K/s   in 26s     

2011-08-01 22:22:16 (22.4 KB/s) - `bambino_core_1.02.jar' saved [595652/595652]

$

Filed a bug #377319 for the Doc change, cannot assign directly.
Comment 8 Ciaran McCreesh 2011-08-01 20:31:41 UTC
But we want to know the filename before we start to fetch it. Multiple packages are allowed to have the same filename in their downloads list.