On Mar 27, 2011, at 1:36 AM, Anders F Björklund wrote: >> Now comes the hard part I've been hinting at from the very beginning. How >> to actually unpack the archive "fully" on the target machine. [...] Now we >> know that Portfiles are just Tcl scripts which use commands declared by the >> "Port system" (version 1.0 in this case), and in fact almost nothing of what >> you see above is in the standard Tcl command set but rather a part of the >> port system runtime, but the most relevant command here is at the very end: >> post-install > > Many of the current Portfiles are trying to do *way* too much in Tcl, that > would be much better off integrated into base proper or implemented as an > extension. I think that making ports/specs/recipes into programs, rather than > markup with a tiny bit of dynamic content allowed is a mistake. But that's > another discussion.
I agree that it's something of a separate discussion, and I might add that the original concept for MacPort was to have Portfiles be in XML and entirely "passive" in the nature of their data, e.g. no active scripts or otherwise un-auditable operations for security / robustness reasons. Our thinking was that we wanted to be able to roll back all the operations for a given port when encountering a failure or explicit "undo" request, which is kind of hard when it's just executed a shell command which has just done god-only-knows-what to the system, and I think those goals were extremely worthy. There were a number of reasons we didn't end up doing that, however, some of which I'll note here in order to inform future discussions on the topic: 1. It was hard to express conditional / looping behavior without duplicating a lot of data and/or having to express the conditionals in a clumsy fashion. You can certainly express predicates in XML with AND, OR and NOT prefixes for each subordinate block, for example, but the resulting overall expression looks a lot more like a conditional in FORTH (which I happen to like but many don't ;-) with an RPN syntax driven by the needs of XML. 2. Humans don't think naturally in XML (see above) and the prototype ports we created were not especially easy to read or maintain, meaning we'd need some sort of "port creator" front end that kicked XML out the back end for novices to be able to create ports, which we thought was important (not everyone who's good at porting software is also comfortable with XML or other markup syntaxes). 3. Port creators like to take short-cuts and otherwise avoid repetitive labor since the process of porting the software itself is difficult enough without having to spend 2X the time just struggling to re-implement an installation script or make(1) procedure which originally came with the port in an entirely passive syntax like XML. If you can't use shell commands directly, you can't cut and paste from the original software's "make install" procedure and we figured that would be really unpalatable to a lot of folks (and I think we were right in this respect). By comparison, a lateral move to slightly different shell commands or built-in procedures like xinstall is a lot easier to grasp. I also don't think the problem lies with Tcl itself. If you look at most Portfiles, they're not actually using Tcl as a programming language in at least 99% of the cases (OK, I just pulled that number out of my ass and I admit it) but rather as a declarative syntax. The port name is foo, the version is bar, and so on, and that was definitely a deliberate design decision on our part. Where Tcl is actually used to loop over argument lists or glob files, it's the exception rather than the rule. I agree that it still makes things problematic from a runtime / packaging perspective, however, and we should probably continue that discussion in the other thread since, as you say, this was actually a premature send on your part. :-) - Jordan
_______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
