Support .dmg disk images as distfiles with new use_dmg option

[Jordan K. Hubbard]

On Dec 20, 2007, at 5:06 AM, Ryan Schmidt wrote:

>> What happens if someone specifies "use_bzip2 yes" and also "use_dmg  
>> yes"?
>
> If you do that, I believe the universe explodes. It is, as you  
> rightly point out, a single extract type that's being selected by  
> these various options.
>
> Before writing the patch in the above ticket, I wrote a very long  
> email detailing how I was unhappy with how the selection of the  
> extraction type was being handled, how two separate tasks  
> (decompression and extraction) were being lumped into one command,  
> and how while this was great for things like .tar.gz and .tar.bz2  
> where a Unix pipeline makes sense, piping the output of the  
> decompression program (gzip or bzip2) into the input of the  
> extraction program (tar), it didn't provide room for growth in the  
> direction of for example .dmg.gz or .dmg.bz2 (which does exist out  
> there among developers who perhaps do not realize that disk images  
> can be compressed) since the .dmg file needs to exist on disk for  
> hdiutil to be able to use it.

It's not clear to me that MacPorts needs to cater to every  
combination, however.  Yes, in theory it's perfectly possible to bzip  
or gzip a disk image, but in reality you'd be much better off choosing  
a compressed disk image type (and if that's not an option in the dmg  
creation code, it probably should be).  Similarly, you'd not expect to  
create .rpm.bz2 files or .zip.gz files (OK, we don't support .zip  
files, but as an example) - certain combinations are just  
nonsensical.   Given everything else on MacPorts' plate, I'd have to  
say that separating these two sub-phases out seems pretty low priority.

- Jordan