Summary: | emerge should call wget --content-disposition | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Martin Mokrejš <mmokrejs> |
Component: | Core - External Interaction | Assignee: | PMS/EAPI <pms> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Martin Mokrejš
2011-08-01 18:26:10 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" No, did not know, thanks. ;-) (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 *** (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 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. (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. (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. 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. |