[MacPorts] #33037: background archiving
MacPorts
noreply at macports.org
Sat Jan 28 08:12:30 PST 2012
#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
More information about the macports-tickets
mailing list