tracking down extraction

[Ryan Schmidt]

On Jun 13, 2008, at 18:52, Alan Batie wrote:

> Joshua Root wrote:
>
>> Does running with -d reveal anything useful?
>
> Mainly that it seems to think it already did it:
>
> ...(a bunch of dependency checking)...
> DEBUG: Searching for dependency: pkgconfig
> DEBUG: Found Dependency: receipt exists for pkgconfig
> DEBUG: Skipping completed org.macports.main (glib2)
> DEBUG: Skipping completed org.macports.fetch (glib2)
> DEBUG: Skipping completed org.macports.checksum (glib2)
> DEBUG: setting option extract.cmd to /opt/local/bin/bzip2
> DEBUG: Skipping completed org.macports.extract (glib2)
> DEBUG: Executing org.macports.patch (glib2)
> --->  Applying patches to glib2
> Error: Target org.macports.patch returned: couldn't change working  
> directory
>
>> The child interpreters run the code in the port1.0 directory, so  
>> you would want to look at portextract.tcl there in order to  
>> continue tracing.
>
> Found it: bzip2 was the old tiger version that wouldn't run, so I  
> removed it and reinstalled.  I had to do another "port clean", but  
> now things are working again.
>
> Several problems seem to be present:
>
> 1.  the port installer has a dependency on a port.  Granted, not a  
> total one, it falls back to unzip if it doesn't find bzip2, but if  
> it's broken...  That's kind of a minor issue though, if the command  
> execution error was detected.

MacPorts will use the system's bzip2 if it finds none in the MacPorts  
prefix. But it found one in the MacPorts prefix so it used that  
instead. It might be wise for MacPorts to always use the system's  
<whatever> in these cases...

N.B.: unzip and bzip2 are different programs handling different  
compression algorithms; they are not interchangeable.

> 2.  there seems to be redundancy in the ports vs the system.  osx  
> (at least leopard) comes with bzip2, and I'm sure that would have  
> worked, but the one in the ports overrode it.  It was installed as  
> a dependency of gnupg.  Likewise, because I use a lot of the perl  
> libraries, it's updating perl to 5.8.8, which is standard in leopard.

It is by design that we have ports for things which are already in  
Mac OS X and that these are used in preference to the system's  
versions. See the FAQ:

http://trac.macports.org/wiki/FAQ#WhyisMacPortsusingitsownlibraries

> 2.  The big problem is that the execution failure wasn't detected.   
> The big port upgrade got started, so I can't really test options to  
> fix this, but you guys probably know your tcl better than I  
> anyhow.  It could be that tar isn't catching the error properly  
> itself; I would guess in that case the only way to fix this would  
> be decompress separately, which would be ugly.

Agreed -- extract/decompression failure should cause an error message  
to be displayed and the port process to halt, just like fetch/ 
configure/build/destroot/install failures already do.

I've thought of separating decompression from extraction before. It  
would make some things a lot easier, like for those archive formats  
whose dearchiving helpers cannot accept input via a pipe, for example  
hdiutil for mounting disk images: we cannot currently handle a  
distfile which is a gzipped (or bzip2'd or otherwise externally  
compressed) disk image. If we separated extraction from compression  
this would be no problem at all. Also, for programs distributed in  
uncompressed tar archives, it would be a simple matter to specify  
that no decompression is needed, whereas now this is a bit of a kludge.

I can't at the moment remember what the arguments against this  
separation were. It would take more disk space temporarily to store  
e.g. the decompressed tar archive while its contents are extracted,  
but that shouldn't be a big deal. Any other reasons we wouldn't want  
this?