[MacPorts] #52450: atk does not activate following install/upgrade due to false positive file exists error with gtk-docs on OS X 10.9 (Mavericks)

[MacPorts]

#52450: atk does not activate following install/upgrade due to false positive file
exists error with gtk-docs on OS X 10.9 (Mavericks)
-------------------------------------------------+-------------------------
 Reporter:  ben@…                                |      Owner:  macports-
     Type:  defect                               |  tickets@…
 Priority:  Normal                               |     Status:  new
Component:  ports                                |  Milestone:
 Keywords:  install, upgrade, outdated, file     |    Version:  2.3.4
  conflict, atk, at-spi2-atk,                    |       Port:  atk
-------------------------------------------------+-------------------------
 OS version: 10.9.5
 uname -a: Darwin redacted.example.org 13.4.0 Darwin Kernel Version 13.4.0:
 Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64

 The build for atk 2.22.0 fails to complete as either stand alone (64-bit)
 or universal due to what appears to be a false positive error regarding
 moving (renaming) the documentation files to the live directory.
 Everything else appears fine with the build so it should work if only it
 gets past this little thing and then allows the registry to update.

 The major problem, however, is the flow on effect through preventing
 installation of at-spi2-atk and upgrading of, well, basically all of
 gnome, bash, cmake, wine, various libraries and all text processing tools.
 Probably a good deal more than that.

 The actual error is this:

 {{{
 :error:activate org.macports.activate for port atk returned: error
 renaming
 "/opt/local/var/macports/software/atk/mpextract0k6HadQ1/opt/local/share
 /gtk-doc/html/atk/atkobject.html" to "/opt/local/share/gtk-
 doc/html/atk/atkobject.html": file already exists
 :debug:activate Error code: POSIX EEXIST {file already exists}
 :debug:activate Backtrace: error renaming
 "/opt/local/var/macports/software/atk/mpextract0k6HadQ1/opt/local/share
 /gtk-doc/html/atk/atkobject.html" to "/opt/local/share/gtk-
 doc/html/atk/atkobject.html": file already exists
 }}}

 Full details are in the log file attached.

 Obviously, I checked to make sure that the file wasn't there and it
 wasn't.  The same is true of /opt/local/share/gtk-
 doc/html/atk/AtkObject.html and running the attempts to activate or
 install with force flags, binary installations, no dependencies or the
 opposite makes no difference.  Installations are cleaned and usually force
 deactivated between attempts.

 I've also tried renaming /opt/local/share/gtk-doc/html/ and creating an
 empty html directory there, the only difference in that case was the new
 directory was deleted when the activation failed.  So leaving some other
 file in the /opt/local/share/gtk-doc/html/atk/ directory was attempted to
 see if it left any other relics of its attempt behind, but no, there
 weren't any.

 I do have the built tarball in /opt/local/var/macports/software/atk/ still
 and could run through it manually, but require advice on which parts of
 the registry the install and upgrade or activation commands modify to make
 it live.  I am aware that this is a sub-optimal solution (and that most
 people should never try it), but too many things depend on this package
 and that's still preferable to a scorched earth response.  I have over 800
 active ports and many of them are essential, whereas the scorched earth
 solution takes days or weeks to complete with full system and network
 resources tied up which is unacceptable at this time (over a holiday
 period, sure, but not now).

 Alternatively I can custom compile the damn thing over in /usr/local (or
 some alternative location) if it is possible to force at-spi2-atk to use
 that path and ignore the ports failure, then everything else shoud return
 to normal.

 If you really want, I can also provide the build directory contents for
 the atk builds, but that hardly seems likely to help.  Still, if needed it
 can be provided.  The commands attempted include:

 {{{
 sudo port -v -d -n install -b -p -f atk
 sudo port -v -d -n install -k -p -f atk
 sudo port -v -d -n install -p -f atk
 sudo port -v -d -n install -f atk
 sudo port -v -d install -f atk
 sudo port -v -d -n install -b -p -f atk +universal
 sudo port -v -d -n install -k -p -f atk +universal
 sudo port -v -d -n install -p -f atk +universal
 sudo port -v -d -n install -f atk +universal
 sudo port -v -d install -f atk +universal
 }}}

 Along with the less verbose options preceding those.

 Force deactivation works, but force activation produces the same error as
 installation and upgrade attempts.  Which makes sense since it is the
 point of activating any installations or upgrades which fails.

 Leaving the force (-f) and the no dependency (-n) flags out makes no
 difference, though in some cases with attempts to upgrade other outdated
 packages it will affect how much of the upgrade is attempted and depending
 entirely on how much of the process can be done before the atk dependency
 is mandatory.  None of those outdated packages successfully upgrade either
 way.

 There is currently approximately thirty outdated packages affected by
 this, including gtk3, but that number will grow.

-- 
Ticket URL: <https://trac.macports.org/ticket/52450>
MacPorts <https://www.macports.org/>
Ports system for the Mac operating system