[76684] trunk/dports/sysutils/rpm/Portfile

[Jeremy Lavergne]

> MacPorts could be enhanced to allow maintainers to add distfile size to a portfile. I don't think that's a particularly useful thing to do

I can think of only one use for knowing "distfilesizes" ahead of time: fail-fast of fetch phase. If the server says the file is a different size, don't even bother downloading.

I'm left wondering if it's worthwhile to track the file size for every revision of every distfile. As we've pointed out, the security issue is already handled by checksums.

I suspect only our non-broadband users would be interested in such functionality.

> however, given that people can just use "port distfiles" and "curl -I".

By no means is "run this set of obscure commands" the Mac way, which I believe MacPorts strives to follow. While it'd be nice for the GUI (an always separate topic of malcontent), I don't recall any MacPorts-based ones having this functionality presently.

This appears to be a situation where we can easily improve our user experience.

I believe `port` could handle the addition of a user-friendly message from a HEAD request, appended to the standard ui_msg:

   ---> Fetching PORTNAME (WX.YZ MB)

While I can't whip up Tcl on a whim, I envision something similar to this:
    set msg "Fetching portname "
    if fetch.type in {http, ftp} do msg-append curl::getsize(distfile)
    ui_msg msg

Depending on how base already handles this message for multiple distfiles, we would either have a sum of all distfiles being appended or print the curl::getsize out for each distfile.

This change should also work gracefully if the fetch phase is ever threaded (enabling download X at a time, continue downloading dependencies while compiling, etc).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3749 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110306/10c59643/attachment-0001.bin>