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

[Jordan K. Hubbard]

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.  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. :-)

I think there's also probably A Better Way To Do This Kind Of Thing in general for macports, which is to allow the power user to specify a Tcl expression which is run in the context of each Portfile as a target in its own right (or, for extra credit, you could also allow the expression to replace a given target, like pre-fetch or build).  Possible syntax: ``port eval "expr" portspec'' or ``port eval -target=pre-fetch "expr" portspec''.  Then you could pass the curl getsize inside an iterator over $distfiles as a fragment of tcl to evaluate at the appropriate time, once macports has built up a suitable Tcl interpreter.  Actually, this suggests all kinds of interesting debugging options, including being able to put passive debugging points inside the portfiles themselves which only activate when a script is passed in but allow the portfile author to export certain information at the best possible time.  Presumably such a debugging framework could also use the return values from the injected code to determine whether execution within the port should continue, allowing a portfile developer / power user to short-circuit parts of the target chain at will.

- Jordan