Jordan K. Hubbard wrote: > On Mar 6, 2011, at 7:16 PM, Jeremy Lavergne wrote: > >> * provide dialup user valuable information about download size >> (can I download this now or wait for overnight) > > Ah, there's the usage case I was looking for earlier, when I called into > question the usefulness of the entire idea. ;-) > > Hmmm. So, presumably, our hapless dialup user can type "port getsize nmap" > and quickly and easily see the size of not just nmap, but all the other deps > he is going to have to download in order to build it (let's assume a fresh > macports install).? OK, that's actually a pretty reasonable thing to want to > have, but it still seems to fit into the feature creep category for me.
I think the modern translation of that would be something like "can I download this now on the mobile broadband, or should I wait for wifi", but whatever. I think we had this same discussion about the "curl -R" (remote time) implementation that we have now with the "curl -I" (head getsize) implementation too... > The next thing that same user is going to want is a way to dump all of the > URLs to all the files that would be downloaded so that he can mail himself > the list and go grab them all at work, after which he also wants some sort of > port distfile migrate command which copies them off of his USB thumb drive > appropriately, or looks in a specific directory first, or whatever (I think > we can do the latter thing already with an environment variable or > something?). Bang, you're off to the races with mostly dialup user features > that nobody else cares about. :-) Actually, outputting metalink* xml files seems rather popular ? * http://www.metalinker.org/ Even better would be to build the ports into packages at work (on a faster box), and then just install them later at home... ;-) --anders _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
