Support .dmg disk images as distfiles with new use_dmg option

Ryan Schmidt ryandesign at macports.org
Thu Dec 20 05:06:34 PST 2007


On Dec 20, 2007, at 06:46, Rainer Müller wrote:

> Ryan Schmidt wrote:
>> I got one comment in the ticket from Maun Suang. Any other  
>> comments from
>> anyone? Anyone else interested in this feature? Anyone think this  
>> is a
>> bad idea? Anyone indifferent to it?
>
> I am interested in this feature, but unfortunately I have not had time
> yet to test the patch :-(
>
> BTW, as we have all these use_foo options, wouldn't it be better we
> would have something like extract.type which can be set to one of  
> bzip2,
> gzip, dmg?

I was hoping nobody would bring this up. :)

> 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.

I was hoping to avoid having to send that email and thereby begin  
this discussion until after the necessary basic support for  
extraction from dmgs, as per my ticket, was committed to base.



More information about the macports-dev mailing list