Hello, 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.square.matrix.R>, is.symmetric.matrix <https://rdrr.io/cran/matrixcalc/src/R/is.symmetric.matrix.R>, and is.positive.definite <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 <profjcn...@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@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
