background archiving

[dave@…]

I have my archives set to use xz, which is great for conserving disk space, but it makes installation incredibly slow. It would be awesome if you could do the archiving in the background

[neverpanic (Clemens Lang)]

I doubt that will be possible, since MacPorts' install process is actually unpacking that very archive, but one could think about copying destroot instead and do the archiving in background.

[ryandesign (Ryan Carsten Schmidt)]

Note that setting your archive type to xz also means you won't receive archives from our buildbot, which only packages tbz2 versions at this time.

[ryandesign (Ryan Carsten Schmidt)]

Note also that using xz as your archive type is problematic if your only copy of the xz program comes from MacPorts. I don't know if Lion includes a copy of xz, but I know that Snow Leopard and earlier do not. The problem arises when you try to upgrade the xz port. During the install phase, MacPorts creates an archive of the destroot, using, as you requested, xz-compressed tarball format. Then in the deactivate phase, it deactivates your existing copy of xz (meaning the xz program gets deleted). Then the activation phase fails because there's no xz program available to decompress the new archive. It becomes even more fun when you realize you can no longer install or activate any port at all. To recover, you would have to clean the xz port, set the archive type back to bz2, and rebuild xz, letting it this time install a bz2 archive, which OS X's bzip2 program can decompress.

Copying the destroot, as cal suggested above, would work around this particular problem, but it would mean that the activation code would have to have two codepaths -- one for when you're using a pre-existing binary archive (extract it), and one for when you're building from source (copy the destroot). You can't just always copy the destroot, because when using an existing binary archive, there is no destroot; the fetch, extract, patch, configure, build and destroot phases aren't even run.

[dave@…]

Replying to cal@…:

I doubt that will be possible, since MacPorts' install process is actually unpacking that very archive, but one could think about copying destroot instead and do the archiving in background.

I'm guessing that you're describing a change to macports' internal code, and “destroot” refers to the place where the files are staged temporarily for archive creation? The described change to the activation code doesn't sound too onerous to me, though I of course don't have to do it. The benefits of installing/updating faster on a multicore machine seem like they would be well worth it.

[mojca (Mojca Miklavec)]

Cc Me!