[R-pkg-devel] check cross-references error: Non-file package-anchored link(s)

[Duncan Murdoch]

On 02/07/2020 10:41 a.m., Dr. Jens Oehlschlägel wrote:
> Thank you for the advice Duncan,
> 
> But let's not get carried away here: we are talking about a *warning* that only arises if two packages are checked together that are never meant to be installed together.
> The new packages contain weeks of improvement-work, and I am not going to add back-and-forth-trick-work just to circumvent some warnings that arise only at the point of switching from old to new.

That's a choice, but your package might face auto-rejection on CRAN. 
Asking CRAN to handle your update manually means extra work for them; if 
there's a simple way to handle it without that (and I've given you two 
to choose from), it seems kind of selfish not to use it.

BTW, assuming you got the two packages on CRAN, it wouldn't be hard for 
a user to install the new bit without updating ff:  just have both 
installed before your update, then ask to update bit.  Since it doesn't 
depend on ff, it won't trigger an ff update.  You can't expect R to know 
they were never meant to be installed together unless you record that 
fact in the dependencies in the DESCRIPTION file.

Duncan Murdoch


> 
> If there is a problem when checking the new packages together that's a different story and worth taking care about. I didn't find such problems.
> 
> Kind regards
> 
> 
> Jens
> 
> 
> 
>> Gesendet: Donnerstag, 02. Juli 2020 um 15:23 Uhr
>> Von: "Duncan Murdoch" <murdoch.duncan using gmail.com>
>> An: "Dr. Jens Oehlschlägel" <jens.oehlschlaegel using truecluster.com>, r-package-devel using r-project.org
>> Betreff: Re: Aw: Re: Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)
>>
>> On 02/07/2020 7:49 a.m., Dr. Jens Oehlschlägel wrote:
>>> Duncan,
>>>
>>>> One way is to make bit depend on a particular version of ff.  That may
>>>> cause a deadlock if both are being updated at once, but I think CRAN
>>>> should be able to deal with it if they are informed of the issue.
>>>
>>> Exactly that I have done: I submitted all three packages bit/bit64/ff in version 4.0.2 and made them dependend on Version >= 4.0.0.
>>> And yes, the maintainers have been informed about the issue.
>>
>> I'm not sure that's what I meant, but I can't be sure, since I haven't
>> seen your source.  What I meant is a package dependency, i.e. the
>> existing ff on CRAN is version 2.2-14.2 and it depends on bit without
>> saying what version of bit is needed.  The existing bit is 1.1-15.2 with
>> no dependency on ff.
>>
>> So you can force the new ff to use the new bit by giving the version
>> number, e.g.
>>
>> Depends:  bit (>= 2.0)
>>
>> but it's not so obvious how to make the new bit depend on the new ff.
>> There's no way to say that the dependency is only to a help page, and
>> circular strong dependencies are messy, so I'd suggest you use one of
>> the other options I offered:  a dynamic link in the Rd file, or no link
>> at all.
>>
>> Duncan Murdoch
>>