[MacPorts] #72645: R-ellipsis @0.3.2: configure failure due to wrong github.tarball_from (was: R-ellipsis configure failure)

[MacPorts]

#72645: R-ellipsis @0.3.2: configure failure due to wrong github.tarball_from
-------------------------+--------------------------
  Reporter:  marcbn      |      Owner:  barracuda156
      Type:  defect      |     Status:  assigned
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:
Resolution:              |   Keywords:
      Port:  R-ellipsis  |
-------------------------+--------------------------
Changes (by ryandesign):

 * status:  new => assigned
 * owner:  (none) => barracuda156
 * cc: barracuda156 (removed)
 * cc: jmroot (added)


Comment:

 Replying to [ticket:72645 marcbn]:
 > Looks like maybe the files are getting unzipped in the wrong directory:
 r-lib-ellipsis-ec6b2f5 instead of ellipsis-0.3.2?

 Yes, and there is a long explanation for why.

 MacPorts used to automatically rename wrong extract directories. This
 feature was found to cause more problems than it solved and was removed.
 Ports that want this behavior must now opt in by setting `extract.rename
 yes` if they cannot specify the correct extracted directory name in
 `worksrcdir`.

 The github portgroup automatically sets `extract.rename yes` when it is
 used to get an automatically-generated tarball (`github.tarball_from` has
 the value `tarball` or `archive`) because GitHub's automatically-generated
 tarballs use unpredictable extracted directory names. Ports downloading
 releases from GitHub (`github.tarball_from` has the value `releases`) do
 not get `extract.rename yes` automatically since they usually don't need
 it since release tarballs are named predictably when they are manually
 created by the developers.

 This port uses the github portgroup indirectly via the R portgroup.

 Back when this port was last updated, the github portgroup defaulted to
 `github.tarball_from tarball`. This value was deprecated but many portfile
 authors did not realize this, so its use continued. This was recently
 changed: all ports that use the github portgroup and that did not already
 specify a value for `github.tarball_from` were changed to explicitly
 specify `github.tarball_from tarball` and then the default in the
 portgroup was changed: ports that fetch from a tag now default to
 `github.tarball_from releases` and those that fetch from a commit default
 to `github.tarball_from archive`. As ports are updated, ports that specify
 `github.tarball_from tarball` should switch to one of the other two
 values, whichever is correct for that project.

 When this change was made, I assume that only ports that include the
 github portgroup were fixed. Since this port does not directly include the
 github portgroup, it was not fixed, and so it now fetches from the wrong
 upstream location:

 {{{
 % sudo port clean --all R-ellipsis
 --->  Cleaning R-ellipsis
 % sudo port fetch --no-mirrors R-ellipsis
 --->  Fetching distfiles for R-ellipsis
 --->  Attempting to fetch ellipsis-0.3.2.tar.gz from
 https://github.com/r-lib/ellipsis/releases/download/v0.3.2
 Error: Failed to fetch R-ellipsis: The requested URL returned error: 404
 }}}

 This project doesn't offer release downloads so trying to fetch from
 releases is wrong.

 When this fails, MacPorts tries to get the file from our mirrors, where it
 finds a copy of the automatically-generated tarball we had originally
 mirrored. However MacPorts thinks it has received a release download, one
 for which the extract directory does not need to be renamed.

 This needs to be corrected in this port and all other ports that use the
 github portgroup indirectly that don't already specify
 `github.tarball_from` by adding these lines to them:

 {{{
 # Change github.tarball_from to 'releases' or 'archive' next update
 github.tarball_from tarball
 }}}

 Looks like this was already [ticket:72232 noticed with another R module,
 R-magrittr], but only that port was fixed. Let's fix all of the remaining
 ports this time.

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