On Dec 6, 2007, at 06:05, Ryan Schmidt wrote:

I'd like MacPorts to support distfiles in .dmg disk image format, in addition to the .tar.gz, .tar.bz2 and .zip formats currently supported.

I spent some time working on this tonight and came up with an implementation that works for me. It's my first bit of hacking in MacPorts base, though, so I'd appreciate any and all feedback, both on the idea and the implementation.

Here's the ticket, which includes the patch:

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

Thanks.

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?

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.

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