[R-pkg-devel] Question about preventing CRAN package archival

Ben Staton @t@tonbe @end|ng |rom gm@||@com
Wed Jun 2 19:15:06 CEST 2021


Thank you for your detailed list of solutions.

I was initially tempted to go with option 1 (move matrixcalc to suggests
and check for its existence before using functions that rely on it), but as
mentioned, this is not a long term fix.

I unfortunately can't take on the responsibilities of option 2 (becoming
the package maintainer) -- there is much that this package does that I do
not understand, and do not wish to feign authority!

I plan to take option 3 (copy the needed functions into my package). There
are only three functions I need from matrixcalc, and all three are fairly
simple (is.square.matrix
<https://rdrr.io/cran/matrixcalc/src/R/is.symmetric.matrix.R>, and
<https://rdrr.io/cran/matrixcalc/src/R/is.positive.definite.R>) and there
is only one function in postpack that needs them. I plan to define them
within the postpack function. matrixcalc is licensed under GPL >= 2 and
based on my scan of the license text, this is allowed. Is that correct?

Regarding option 4 (contacting the matrixcalc maintainer), the original
email from CRAN mentioned that they have attempted to contact the package
author with no response.

Thank you!

On Wed, Jun 2, 2021 at 9:52 AM J C Nash <profjcnash using gmail.com> wrote:

> I just downloaded the source matrixcalc package to see what it contained.
> The functions
> I looked at seem fairly straightforward and the OP could likely develop
> equivalent features
> in his own code, possibly avoiding a function call. Avoiding the function
> call means NAMESPACE etc. are not involved, so fewer places for getting
> into
> trouble, assuming the inline code works properly.
> JN
> On 2021-06-02 12:37 p.m., Duncan Murdoch wrote:
> > 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 using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel

	[[alternative HTML version deleted]]

More information about the R-package-devel mailing list