Bug 3040 – poor handling of download CGIs

• Product: Portage Development
• Status: RESOLVED INVALID

[Description Ryan Shaw 2002-05-26 03:16:12 UTC]

i have run into a problem with an ebuild i am creating. 
the SRC_URI is of the form:

http://www.foo.org/download.cgi?location=libfoo-1.0.tar.gz

portage fetches the tarball okay, but the digest generation fails.

the offending code in portage.py (line 1050):

	#uri processing list
	upl=[[newuris,alist],[alluris,aalist]]
	for myl in upl:
		for x in myl[0]:
			mya=os.path.basename(x)
			if not mya in myl[1]:
				myl[1].append(mya)

os.path.basename() returns "download.cgi?location=libfoo-1.0.tar.gz"
as the name of the archive. but this is not the correct filename so the 
checksum fails:

  File "/usr/lib/python2.2/site-packages/portage.py", line 69, in perform_checksum
    return fchksum.fmd5t(filename)
IOError: [Errno 2] No such file or directory: 
'/usr/portage/distfiles/download.cgi?location=libfoo-1.0.tar.gz'

[Comment 1 Seemant Kulleen (RETIRED) 2002-05-26 03:21:43 UTC]

could you attach your ebuild?

[Comment 2 Ryan Shaw 2002-05-26 03:48:09 UTC]

Created attachment 1148 [details]
failing ebuild

this is the ebuild in question, which attempts to use a
download CGI to get the source tarball.

[Comment 3 Seemant Kulleen (RETIRED) 2002-05-26 04:54:03 UTC]

question is, do we want to hack around portage, or is this a problem enough that
we need to accommodate it in portage?

[Comment 4 Ryan Shaw 2002-05-26 05:46:13 UTC]

I'm willing to hack around portage to get this paticular 
ebuild working for now, but i'm not sure how to do it...

But download CGIs are not that uncommon. This seems like
something portage should handle.

[Comment 5 Ryan Shaw 2002-05-29 02:13:37 UTC]

okay, fortunately i figured out that you can get around the
download CGI on the hoard site by mangling the URL, so this
bug is no longer blocking me. i still think it ought to be
fixed, though...

[Comment 6 Nicholas Jones (RETIRED) 2002-11-14 06:06:44 UTC]

Not something portage can figure out.