Hello all. The github 1.0 portgroup does some post-extract shenanigans to normalize the result of extracting the distfile: e.g. a GitHub project `me/myproject` will, as retrieved from GitHub, extract to `me-myproject-0123abc`; this is moved to `myproject` via globbing: https://github.com/macports/macports-ports/blob/46c352bcc820ef80909e27a57d2f5eb71569abc6/_resources/port1.0/group/github-1.0.tcl#L81
### My question I am wondering why the above is done rather than doing the following, which extracts directly to the desired `worksrcpath`: extract.mkdir yes extract.post_args-append --strip-components=1 Example extract invocation (simplified): cd "/path/to/worksrcdir" && /usr/bin/gzip -dc '/path/to/distfile.tar.gz' | /usr/bin/tar -xf - --strip-components=1 This seems to nicely solve the problem without relying on the format of the tarball root. Is there a reason we are not using this solution? ### Background The following confluence of issues led me to the above solution: 1. The golang portgroup has specific requirements for the worksrcdir related to the GOPATH (long story) 2. The github portgroup post-extract manipulations require that the worksrcdir be already present, or that the result of extraction matches the expected format 3. When `github.tarball_from` is `release` the result of extraction is unpredictable, so it needs to be handled by the port 4. The github portgroup's post-extract block can't be overridden or pre-empted, so additional post-extract blocks can't resolve this conflict The `extract.mkdir yes` solution ensures that the worksrcdir is correct regardless. An alternate solution might involve a flag to enable or disable the github portgroup's post-extract manipulations, or a new variable to specify the expected result of extraction independently of worksrcdir. But these seem inelegant if the `extract.mkdir yes` solution is viable. Thanks, Aaron