To add another option. In the past when this has happened to me I've found other packages that provide similar functionality.
I'm assuming that is.square just checks the number of columns == number of rows? And the others can probably be implemented pretty easily. On Wed, Jun 2, 2021 at 10:41 AM Ben Staton <stato...@gmail.com> wrote: > My package uses the MIT license, so would that not meet the compatibility > requirements? > > I will attempt to reach out to the package author - thanks for your help! > > On Wed, Jun 2, 2021 at 10:31 AM Ben Bolker <bbol...@gmail.com> wrote: > > > That all sounds exactly right. > > GPL >= 2 allows you to use the material without asking permission as > > long as your package is compatibly licensed (e.g. also GPL). > > Under normal circumstances it would be polite to ask permission, but > > if the reason for doing this is that the maintainer is unreachable in > > the first place ... > > > > If you want to try a little harder, it seems quite possible that you > > can reach the matrixcalc maintainer at the (personal) e-mail address > > shown in this page: > > > > > https://www.facebook.com/photo/?fbid=10208324530363130&set=ecnf.1000413042 > > > > (Possibly an identity confusion, but I rate that as unlikely based on > > other facebook snooping) > > > > I don't think a short, polite e-mail request would be out of bounds, > > they can always ignore it or tell you to go away. > > > > cheers > > Ben Bolker > > > > On 6/2/21 1:15 PM, Ben Staton wrote: > > > 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 > > > > > > > ______________________________________________ > > 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 > -- John :wq [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
