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

[Ben Staton]

Hi Everyone, thank you all for your responses.

I agree that I can replicate the three functions within matrixcalc that I
need with ease, even without copying and pasting the original code found in
that package and thus not creating any licensing issues.

I have checked the CRAN incoming boards (here
<https://lockedata.github.io/cransays/articles/dashboard.html>), and they
actually have a new version of matrixcalc coming through so hopefully this
issue will be resolved without my intervention.

On a related note, suppose that this issue does not get resolved before the
archival date, and my package gets archived. What would be the path for me
to have CRAN remove it from the archived list? Is it basically (1) fix the
issue that caused initial archival and (2) resubmit?

Thank you,
Ben

On Wed, Jun 2, 2021 at 12:48 PM Spencer Graves <
spencer.graves using effectivedefense.org> wrote:

>           The CRAN maintainers almost certainly have tried to contact the
> maintainer.  You can ask if he plans to fix the bug.  If not, if it's
> that easy to fix, you could offer to both the maintainers of both
> matrixcalc and CRAN to take over maintenance.
>
>
>           Spencer
>
>
> On 6/2/21 2:41 PM, Roy Mendelssohn - NOAA Federal via R-package-devel
> wrote:
> > After looking up matrixcalc on CRAN,  I would recommend contacting the
> maintainer,  who is listed as:
> >
> >> Frederick Novomestky <fnovomes at poly.edu>
> >
> >
> > The reason I say this is what is blowing up the package in the nightly
> builds is a careless error in one Example:
> >
> >>    > x <- matrix( c( 2, 4, 2, 1, 3, 1, 5, 2, 1, 2, 3, 3 ), nrow=4,
> ncol=4, byrow=TRUE )
> >>      Error in matrix(c(2, 4, 2, 1, 3, 1, 5, 2, 1, 2, 3, 3), nrow = 4,
> ncol = 4, :
> >>       data length differs from size of matrix: [12 != 4 x 4]
> >>
> >
> > That should be pretty easy for the maintainer to fix and to resubmit.
> >
> > -Roy
> >
> >
> >> On Jun 2, 2021, at 10:36 AM, Ben Staton <statonbe using 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 <bbolker using 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 <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]]
> >>>>
> >>>> ______________________________________________
> >>>> R-package-devel using r-project.org mailing list
> >>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>>>
> >>>
> >>> ______________________________________________
> >>> R-package-devel using r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>>
> >>
> >>      [[alternative HTML version deleted]]
> >>
> >> ______________________________________________
> >> R-package-devel using r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
> > **********************
> > "The contents of this message do not reflect any position of the U.S.
> Government or NOAA."
> > **********************
> > Roy Mendelssohn
> > Supervisory Operations Research Analyst
> > NOAA/NMFS
> > Environmental Research Division
> > Southwest Fisheries Science Center
> > ***Note new street address***
> > 110 McAllister Way
> > Santa Cruz, CA 95060
> > Phone: (831)-420-3666
> > Fax: (831) 420-3980
> > e-mail: Roy.Mendelssohn using noaa.gov www: https://www.pfeg.noaa.gov/
> >
> > "Old age and treachery will overcome youth and skill."
> > "From those who have been given much, much will be expected"
> > "the arc of the moral universe is long, but it bends toward justice"
> -MLK Jr.
> >
> > ______________________________________________
> > R-package-devel using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

	[[alternative HTML version deleted]]