Le 13 sept. 07 à 12:43, Ryan Schmidt a écrit :

So we had a problem with the gcc43 port (until it was fixed in r29009) where just attempting to install gcc43 rendered the entire port system unusable, because MacPorts couldn't process the receipt that got installed. See this ticket:

http://trac.macports.org/projects/macports/ticket/12698

The problem occurred when variant descriptions were added to the port like this (in r28362):

variant odcctools description "some description" { [snip] }

Those of us less familiar with tcl syntax rules (me; probably most of us) probably didn't catch that this should have been written:

variant odcctools \ description "some description" { [snip] }

or:

variant odcctools description "some description" { [snip] }

I don't know enough about tcl to understand why the original version was unacceptable, and in particular, if it was unacceptable, why it didn't blow up much earlier. What surprised me was that "port lint" didn't find anything wrong, and that "port install" didn't complain at all about the port, until the entire thing exploded during the install phase. "port info" gave a slight clue when it printed "(Variants: universal, darwin_8, powerpc, )" (the two variants didn't show up, but there was a comma and a blank after the powerpc variant). "port variants" similarly didn't show the two variants, but had an extra blank line at the end.

What can we do to prevent portfiles malformed in this manner from breaking MacPorts in the future? It seems that there are parts of the code that are assuming things that are not true in portfiles malformed in this way. Perhaps to be more robust we should add more sanity-checking code to base. But I'm not sure where or how.

Shouldn't it just check if variant procedure is called with either 1 or 4 arguments? -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org