[MacPorts] #68440: ijq @0.4.1, kiln @0.4.0: failed to extract: error renaming ...: trying to rename a volume or move a directory into itself (was: ijq @0.4.1: failed to extract: error renaming ...: trying to rename a volume or move a directory into itself)

[MacPorts]

#68440: ijq @0.4.1, kiln @0.4.0: failed to extract: error renaming ...: trying to
rename a volume or move a directory into itself
-----------------------------+-------------------------
  Reporter:  ianthrive       |      Owner:  herbygillot
      Type:  defect          |     Status:  assigned
  Priority:  Normal          |  Milestone:
 Component:  ports           |    Version:  2.8.1
Resolution:                  |   Keywords:
      Port:  ijq, hut, kiln  |
-----------------------------+-------------------------
Changes (by ryandesign):

 * cc: woolsweater, sikmir (added)
 * port:  ijq => ijq, hut, kiln


Comment:

 This may be fallout from
 [changeset:ffdb7d9ee9e59e9d69a2f29ac08dfd5090f84759/macports-base a
 change] which was first included in MacPorts 2.8.1 on January 30, 2023. We
 most recently had successful [https://ports.macports.org/port/ijq/builds/
 builds of ijq] on December 25, 2022.

 Here's what seems to be happening. The ijq port includes the golang
 portgroup, which changes the default `worksrcdir`:

 {{{#!tcl
 default worksrcdir      {gopath/src/${go.package}}
 }}}

 The port calls the portgroup's `go.setup` procedure which, because this
 project is hosted at sourcehut, then includes the sourcehut portgroup and
 calls its `sourcehut.setup` procedure.

 `sourcehut.setup` changes the default `worksrcdir` again:

 {{{#!tcl
     default worksrcdir      {${sourcehut.project}-${git.branch}}
 }}}

 The golang portgroup's post-extract block is documented to do this:

 {{{#!tcl
 # Setup build sources in GOPATH style:
 #   workpath/
 #       gopath/src/example.com/
 #           author1/project1/
 #           author2/project2/
 }}}

 However it does so by creating `${worksrcpath}` (except for the last
 component) and trying to move what was extracted to `${worksrcpath}`,
 apparently not anticipating that anyone would override it in a Portfile or
 in another portgroup. If the golang portgroup is so insistent about its
 `worksrcdir`, it should set it, not its default. However, it also seems
 like a misuse of `worksrcdir`. `worksrcdir` is supposed to refer to the
 name of the top-level extracted directory. It certainly should not contain
 slashes. If any of the phases (extract, patch, configure, build, destroot)
 need to happen in some other directory, that's what the variables
 `extract.dir`, `patch.dir`, etc. are for.

 I would look carefully at all of the ports that use the golang and
 sourcehut portgroups together to see if they have the same problem. That
 appears to be only three ports: ijq, hut, and kiln. I see that kiln fails
 with the same message as ijq while hut succeeds because it contains a
 workaround for this problem that was added when that port was created:

 {{{#!tcl
 # Tarball contents name conflicts with the default work dir name
 worksrcdir          ${name}-${version}-${epoch}
 }}}

 It would be good to fix the problem in one of the portgroups so that the
 strange workaround can be removed from the hut Portfile. There was no
 discussion of this strange workaround in [https://github.com/macports
 /macports-ports/pull/18306 the PR that added the hut port].

-- 
Ticket URL: <https://trac.macports.org/ticket/68440#comment:1>
MacPorts <https://www.macports.org/>
Ports system for macOS