R-ellipsis @0.3.2: configure failure due to wrong github.tarball_from

[marcbn]

Trying to install R-tidyverse and R-ellipsis fails to configure. Looks like maybe the files are getting unzipped in the wrong directory: r-lib-ellipsis-ec6b2f5 instead of ellipsis-0.3.2?

[alanterra (Alan Harper)]

Same problem. Apple Silicon, Sequoia 15.5.

[alanterra (Alan Harper)]

log file

[ryandesign (Ryan Carsten Schmidt)]

Replying to 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 noticed with another R module, R-magrittr, but only that port was fixed. Let's fix all of the remaining ports this time.

[barracuda156]

Replying to ryandesign:

Ryan, if MacPorts' upstream wants to have R ports working correctly and being updated, I recommend finding a way to pull updates from ​https://github.com/macos-powerpc/R-ports (it is not powerpc-specific and works as a drop-in). There is no requirement to reference me or my repo in any manner or preserve commit history, etc.

Everything R is broken in MacPorts now not only due to port extract failures for packages which use GitHub, but also due to a missed revbump upon R update (so you have pre-built packages installed into a wrong path). Also, a number of packages in existing versions do not build with R 4.5, since there were breaking changes in API (Calloc and Free are now R_Calloc and R_Free, for example). Finally, everything is out-of-date since last updates in Jan.

[barracuda156]

Related issue #72714

[barracuda156]

Related issue #72810

[ryandesign (Ryan Carsten Schmidt)]

Replying to barracuda156:

Ryan, if MacPorts' upstream wants to have R ports working correctly and being updated, I recommend finding a way to pull updates from ​https://github.com/macos-powerpc/R-ports (it is not powerpc-specific and works as a drop-in). There is no requirement to reference me or my repo in any manner or preserve commit history, etc.

Everything R is broken in MacPorts now not only due to port extract failures for packages which use GitHub, but also due to a missed revbump upon R update (so you have pre-built packages installed into a wrong path). Also, a number of packages in existing versions do not build with R 4.5, since there were breaking changes in API (Calloc and Free are now R_Calloc and R_Free, for example). Finally, everything is out-of-date since last updates in Jan.

kjellpk, i0ntempest: FYI

[i0ntempest]

TBH I was never a fan of those a billion R-* ports and I've never touched any of them, as I only install R packages in R itself and I'm guessing it's the same for most R users. I don't know how many of them are still maintained, but since R-* ports are all broken right now and maintained outside the main ports tree, I propose we deprecate and eventually delete all of them from the main ports tree.

[jmroot (Joshua Root)]

Sounds fine to me.

Replying to i0ntempest:

I don't know how many of them are still maintained

Apparently none in our tree.

% port echo 'category:(^|\s)R(\s|$)' and not \( maintainer:barracuda156 maintainer:nomaintainer \)
%

I propose we deprecate and eventually delete all of them from the main ports tree.

A deprecation period may not be very useful if the majority of them are not usable. Or are you thinking along the lines of informing users of the situation when they try to install one?

[ryandesign (Ryan Carsten Schmidt)]

Replying to i0ntempest:

TBH I was never a fan of those a billion R-* ports and I've never touched any of them, as I only install R packages in R itself and I'm guessing it's the same for most R users. I don't know how many of them are still maintained, but since R-* ports are all broken right now and maintained outside the main ports tree, I propose we deprecate and eventually delete all of them from the main ports tree.

It's worth considering. The purpose of a port is so that a user can use it or if another port depends on it. The only ports that depend on any of the R modules are other R modules. If users install R modules from within R then maybe we don't need the module ports.

But 170 of the module ports have patches. This suggests they don't work right without patching—patching which presumably does not occur when installing from within R.

If the ports are kept, then it's important not to break them when updating R.

Replying to jmroot:

Replying to i0ntempest:

I don't know how many of them are still maintained

Apparently none in our tree.

% port echo 'category:(^|\s)R(\s|$)' and not \( maintainer:barracuda156 maintainer:nomaintainer \)
%

According to the maintainers line, many are maintained by Sergey. If that's not accurate, and if the ports are kept, then please correct the maintainers line.

[jmroot (Joshua Root)]

Replying to ryandesign:

According to the maintainers line, many are maintained by Sergey. If that's not accurate, and if the ports are kept, then please correct the maintainers line.

I don't know how to interpret his recent messages other than that he is no longer maintaining these ports in our tree.

[i0ntempest]

Replying to jmroot:

Or are you thinking along the lines of informing users of the situation when they try to install one?

That would be the best course of action, if some users do decide to overlay the external R ports tree over the main one it shouldn't conflict.

Replying to ryandesign:

170 of the module ports have patches

Given the previous maintainer's support targets I would think most of them are fixes for building on archaic arch/OS. And they would still be included in the external tree, should anyone elect to use it.

[barracuda156]

Replying to i0ntempest:

Given the previous maintainer's support targets I would think most of them are fixes for building on archaic arch/OS. And they would still be included in the external tree, should anyone elect to use it.

R ports are generally non-problematic (after all, most of them are simple). There are no gazillion of fixes not because newer OS were left broken, but because not many fixes were needed. I don't think anything of R ports was deliberately fixed only for archaic OS and kept broken otherwise :)

There are some ports which have custom settings to allow linking to MacPorts dependencies (those using gdal, postgresql, mpich, ImageMagick etc.). I don't know how you would do that otherwise, unless repeat similar tweaks locally.

16. S. Keeping R ports exclusively for the sake of 10.5 is pointless, of course, since a lot of other stuff is broken by now anyway.