#33037: background archiving -------------------------------+-------------------------------------------- Reporter: dave@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: base | Version: 2.0.3 Keywords: | Port: -------------------------------+-------------------------------------------- Comment(by ryandesign@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/33037#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS