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

[Jeremy Lavergne]

> Ah, well, yes, you're right of course, I didn't mean that users should use obscure commands; I meant the information is already available via those commands, so we needn't go through thousands of portfiles adding this information and keeping it updated there forevermore, when it's redundant. Certainly MacPorts could be enhanced with a command (port distsize?) that would print the filesizes for you. Or the web site could be enhanced to include that information.

I agree; it sounds less than worthwhile to add "distfilesizes" to the Portfiles.

But I'm not arguing for a command to simply output the distfilesizes: Why not just append curl::getsize() to the standard ui_msg without what seems to be extra work doing the other options?

Going to the MacPorts site to figure out the filesizes would be less than ideal. If it's automated through `port` there may be privacy/tracking issues; if literally visiting the site with a browser then the user needs multiple apps to essentially do one thing.

As far as the approach of adding a command to output filesize, that's an extra command to run.

My goals for this idea are:
 * provide dialup user valuable information about download size
   (can I download this now or wait for overnight)
 * satisfy user curiosity without the clutter of verbose mode
   (this may take a while: >100MB)
 * keep standard output clean
   (no extra lines, while providing a concise output about filesize)

We can satisfy all of these by always showing the download size---no extra command, no need to check in a browser.

Compared to the above ideas, I recommend sticking to modifying the standard ui_msg to append curl::getsize(). 

Your next idea also sounds better ;-)

> Certainly a proper progress bar for downloads in MacPorts would be nice. Currently we just let curl print whatever it wants, but when we have ports like gcc4* that download five large distfiles, it's nice to know the overall progress, not just the progress of each file. But that is the exception; most ports just have one distfile.

This would be interesting to see.

I know the CLI version of curl has two status bars available. Going this route I'd recommend we dump out the single-line status bar while verbose mode continues to use the standard multi-line one. While this would add a line of output foreach distfile, I could argue an additional line or two could be worth the extra feedback granted to the users; it's still way better than verbose mode.

Do we have any concerns with \r in our non-verbose, non-debug output? I don't think we do but I also don't know of any standard messages utilizing \r either. If we avoid it on purpose we should respect that, otherwise this should be a viable enhancement as well.

-------------- 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/e489bd86/attachment.bin>