On 02/06/2021 12:13 p.m., Ben Staton wrote:
Hello,
I received an email notice from CRAN indicating that my R package
('postpack') will be archived soon if I do not take any action and I want
to avoid that outcome. The issue is not caused by my package, but instead a
package that my package depends on:
"... package 'matrixcalc' is now scheduled for archival on 2021-06-09,
and archiving this will necessitate also archiving its strong reverse
dependencies."
Evidently, xyz has been returning errors on new R builds prompting CRAN to
list it as a package to be archived. My package, 'postpack' has
'matrixcalc' listed in the Imports field, which I assume is why I received
this email.
I want to keep 'postpack' active and don't want it to be archived. I still
need package 'matrixcalc' for my package, but not for most functions. Could
I simply move package 'matrixcalc' to the Suggests list and submit the new
version to CRAN to remove the "Strong Reverse Dependency" issue that
triggered this email to avoid CRAN from archiving my package?
That's part of one solution, but not the best solution.
If you move it to Suggests, you should make sure that your package
checks for it before every use, and falls back to some other calculation
if it is not present. Be aware that once it is archived, almost none of
your users will have it available, so this is kind of like dropping the
functions that it supports.
Another solution which would be great for the community might be for you
to offer to take over as maintainer of matrixcalc. Then you'd fix
whatever problems it has, and you wouldn't need to worry about it. I
haven't looked at the issues so I don't know if this is feasible.
A third choice would be for you to copy the functions you need from
matrixcalc into your own package so you can drop the dependency. This
is generally legal under the licenses that CRAN accepts, but you should
check anyway.
A fourth choice would be for you to contact the matrixcalc maintainer,
and help them to fix the issues so that matrixcalc doesn't get archived.
They may or may not be willing to work with you.
I'd say my third choice is the best choice in the short term, and 2nd or
4th would be good long term solutions.
Duncan Murdoch
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
