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'
could you attach your ebuild?
Created attachment 1148 [details] failing ebuild this is the ebuild in question, which attempts to use a download CGI to get the source tarball.
question is, do we want to hack around portage, or is this a problem enough that we need to accommodate it in portage?
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.
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...
Not something portage can figure out.
