The ebuild in question has the following: src_unpack() { unpack ${A} cd ${S} rm -f zipcode.t jigyosyo.t ken_all.{lzh,csv} jigyosyo.{lzh.csv} || die wget http://www.post.japanpost.jp/zipcode/dl/kogaki/lzh/ken_all.lzh \ http://www.post.japanpost.jp/zipcode/dl/jigyosyo/lzh/jigyosyo.lzh lha e ken_all.lzh lha e jigyosyo.lzh touch *.csv } I don't think it is really nice to have a wget line there. Isn't that what the SRC_URI is for?
I very much agree with you. I think "wget within ebuilds" is a very bad idea, maybe except for ebuilds where you would expect such behaviour (cvs live ebuilds). A quick find/grep through portage pointed me to another two ebuilds that use wget: sys-apps/usbutils/usbutils-0.11-r1.ebuild: wget http://www.linux-usb.org/usb.ids app-cdr/cdrdao/cdrdao-1.1.5-r1.ebuild: wget http://cdrdao.sourceforge.net/${P}.drivers Some reasons why I don't like wget here: No md5sums. Must be online, with direct internet connection to build. No proxy, no mirror, no local file storage. No emerge -f. Build 100 times, and the ebuild will fetch the same file 100 times. And you can't reproduce/go back to older versions of ebuilds. Note: you can't simply move the files into SRC_URI when they are 'volatile', with changing md5sums. This may be a reason why people would want to wget here, however, please rather use releases, instead of such everchanging files. Even if this means ie extracting RPMs.
Theses files are updated sometimes as same file name. Therefore it uses wget. But I think it's but idea as well. So I'll change the ebuild to get the file of snapshot I'll make from original server. Thanks, Masatomo Nakano
Fixed the ebuild. It's in CVS. Thanks.
