port doesn't exit with proper return value

[Ryan Schmidt]

On May 17, 2008, at 1:50 AM, Joshua Root wrote:

> Ryan Schmidt wrote:
>> On May 16, 2008, at 7:46 AM, Joshua Root wrote:
>>> Port's normal mode of operation is to run as many of the requested
>>> commands as possible and not exit when a command fails. It does  
>>> this by
>>> suppressing the error status from the commands. This is certainly
>>> incorrect when there's only one command run and it fails, but  
>>> it's less
>>> clear what should happen when some of the requested commands  
>>> succeed.
>>>
>>> You can make the first failed command cause port to exit, with the
>>> appropriate return code, by using the -x option on the command line.
>>>
>>> Related tickets:
>>>
>>> http://trac.macports.org/ticket/13918
>>> http://trac.macports.org/ticket/14928
>> Seems like -x should be the default, or rather, that the -x option  
>> should be removed, and port should always issue an error message  
>> and stop with a nonzero exit status the moment something goes  
>> wrong. Why would one not want that?
>
> I think the idea is that if you run `port install foo bar baz` or  
> `port upgrade outdated`, and one of the ports fails to install/ 
> upgrade, you probably want it to still do the others. This is  
> certainly the case when the operation will take a long time and you  
> want to be able to leave it unattended.

On the contrary, I do want MacPorts to stop as soon as it runs into  
an error. If I say "port upgrade cairo pango graphviz", and graphviz  
depends on pango, and pango depends on cairo, and maybe the latest  
version of graphviz requires the latest version of pango which  
requires the latest version of cairo, and suppose that cairo fails to  
upgrade, then I do not want MacPorts to attempt to upgrade pango or  
graphviz.

I suppose I can see the point if you've asked for the installation of  
various unrelated ports, that it should continue to install the other  
ports even if one fails. But it seems like "most" people would want  
MacPorts to stop and issue and error if an error occurs. The other  
behavior could be available via a flag, for advanced users.


> On reflection, there should probably always be a non-zero exit  
> status when any command fails, but a failure shouldn't cause the  
> batch to stop.