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

help("clone.ff", package = "ff")[[1]]

Good evening,

My package bit 4.0.2 (https://github.com/truecluster/bit) is being
rejected by CRAN checks with warning:

 >Check: Rd cross-references, Result: WARNING
 >  Non-file package-anchored link(s) in documentation object 'clone.Rd':
 >    '[ff]{clone.ff}'
 >
 >  See section 'Cross-references' in the 'Writing R Extensions' manual.

although clone.ff is in clone.ff.rd as confirmed by

 > help("clone.ff","ff")[[1]]

[1] "/home/mypc/R/x86_64-pc-linux-gnu-library/4.0/ff/help/clone.ff"

I asked the maintainers to explain what is wrong and what to do and got
no answer. Does someone here can help?

Best regards

Jens




On 16.06.20 22:31, G?bor Cs?rdi wrote:

This is how to look up the filename. The first "sp" is the topic name,
the second is the package name.

help("sp", "sp")[[1]]

[1] "C:/Users/csard/R/win-library/4.0/sp/help/00sp"

So you need to link to the "00sp.Rd" file:  \link[sp:00sp]{sp}

Gabor

On Tue, Jun 16, 2020 at 9:09 PM Wayne Oldford <rwoldford at uwaterloo.ca> wrote:

Hi

I got caught by this new test this week in trying to push an updated release of the loon package to CRAN.

By following this thread, I corrected my cross-references to external packages but I got stymied by
the one I hoped to give to the  "sp" package for Spatial data

_________

Here is the history:

I tried
    \link[sp:sp]{sp}
which failed here:
Debian: <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_162128/Debian/00check.log>
Status: 1 WARNING


That was meant to correct an earlier attempt (it did for other links to "scales" for example) where I had tried
   \link[sp]{sp}
and  failed here:
Debian: <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200615_213749/Debian/00check.log>
Status: 1 WARNING


So to complete the possibilities as I understand them,  I just now tried
    \link{sp}
which, as might be expected, failed here:
Debian: <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_213921/Debian/00check.log>
Status: 1 WARNING
As expected, error here was different:  "Missing  link"  as opposed to "Non-file package-anchored link"

_________


I am not sure whether I have missed a subtlety in WRE or that the peculiar circumstance
where the package, the topic, and the file name are all identical (sp) is some weird boundary case.

Without further advice, I think I am just going to remove the link to "sp".
It really is just a courtesy link to the package description for "sp".

Thanks in advance for your thoughts.

Wayne




?-----Original Message-----
From: R-package-devel <r-package-devel-bounces at r-project.org> on behalf of Georgi Boshnakov <georgi.boshnakov at manchester.ac.uk>
Date: Tuesday, June 16, 2020 at 9:27 AM
To: G?bor Cs?rdi <csardi.gabor at gmail.com>, Duncan Murdoch <murdoch.duncan at gmail.com>
Cc: List r-package-devel <r-package-devel at r-project.org>
Subject: Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)

     I think that the current behaviour is documented in WRE:

     "...There are two other forms of optional argument specified as \link[pkg]{foo} and
     \link[pkg:bar]{foo} to link to the package pkg, to files foo.html and bar.html respectively.
     These are rarely needed, perhaps to refer to not-yet-installed packages (but there the HTML
     help system will resolve the link at run time) or in the normally undesirable event that more
     than one package offers help on a topic7 (in which case the present package has precedence so
     this is only needed to refer to other packages). They are currently only used in HTML help
     (and ignored for hyperlinks in LATEX conversions of help pages), and link to the file rather
     than the topic (since there is no way to know which topics are in which files in an uninstalled
     package) ...   Because they have been frequently misused, the HTML help system looks for topic foo in package pkg
     if it does not find file foo.html."

     Unless I am missing something, it seems that it would be relatively painless to reverse the logic of the current behaviour of the help system,
     i.e. to start looking first for the topic and then for a file.

     Georgi Boshnakov

     -----Original Message-----
     From: R-package-devel <r-package-devel-bounces at r-project.org> On Behalf Of G?bor Cs?rdi
     Sent: 16 June 2020 13:44
     To: Duncan Murdoch <murdoch.duncan at gmail.com>
     Cc: List r-package-devel <r-package-devel at r-project.org>
     Subject: Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)

     On Mon, Jun 15, 2020 at 5:30 PM Duncan Murdoch <murdoch.duncan at gmail.com> wrote:

     >
     > On 15/06/2020 12:05 p.m., Martin Maechler wrote:

     > >>>>>> Duncan Murdoch   on Sun, 14 Jun 2020 07:28:03 -0400 writes:

     > >

     > >      > I agree with almost everything you wrote, except one thing:  this isn't
     > >      > newly enforced, it has been enforced since the help system began.  What
     > >      > I think is new is that there are now tests for it.  Previously those
     > >      > links just wouldn't work.

     > >

     > >      > Duncan Murdoch

     > >
     > > Yes, to all... including Duncan's agreement with G?bor.
     > >
     > > Also, Duncan M earlier did mention that he had wanted to
     > > *change* the link-to-file behavior for these cases (when he wrote
     > > most of the Rd2html source code) but somehow did not get it.

     >
     > Actually, I don't think I pushed for this change at the time (or at
     > least I didn't push much).  I just wish now that I had, because I
     > think it will be harder to do it now than it would have been then.
     >
     > Duncan

     I am not entirely sure, but maybe just documenting the current behaviour and undoing 78674 could work. With some tweaks? E.g.

     * updating R-exts to say that \link[pkg:topic]{text} will link to `topic.html` in `pkg` first (for historical reasons), and falls back to searching for `topic` in `pkg` at render time.
     * updating Rd2HTML to look for the topic and use it in the link, instead of throwing a warning, in it cannot find `topic.html`
     * removing the `R CMD check` warning for non-file links, that was added in 78674 :)

     Is there anything else?

     Gabor

     [...]

Good evening,

My package bit 4.0.2 (https://github.com/truecluster/bit) is being
rejected by CRAN checks with warning:

  >Check: Rd cross-references, Result: WARNING
  >  Non-file package-anchored link(s) in documentation object 'clone.Rd':
  >    '[ff]{clone.ff}'
  >
  >  See section 'Cross-references' in the 'Writing R Extensions' manual.

although clone.ff is in clone.ff.rd as confirmed by

  > help("clone.ff","ff")[[1]]

[1] "/home/mypc/R/x86_64-pc-linux-gnu-library/4.0/ff/help/clone.ff"

I asked the maintainers to explain what is wrong and what to do and got
no answer. Does someone here can help?

Best regards

Jens




On 16.06.20 22:31, G?bor Cs?rdi wrote:

This is how to look up the filename. The first "sp" is the topic name,
the second is the package name.

help("sp", "sp")[[1]]

[1] "C:/Users/csard/R/win-library/4.0/sp/help/00sp"

So you need to link to the "00sp.Rd" file:  \link[sp:00sp]{sp}

Gabor

On Tue, Jun 16, 2020 at 9:09 PM Wayne Oldford <rwoldford at uwaterloo.ca> wrote:

Hi

I got caught by this new test this week in trying to push an updated release of the loon package to CRAN.

By following this thread, I corrected my cross-references to external packages but I got stymied by
the one I hoped to give to the  "sp" package for Spatial data

_________

Here is the history:

I tried
     \link[sp:sp]{sp}
which failed here:
Debian: <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_162128/Debian/00check.log>
Status: 1 WARNING


That was meant to correct an earlier attempt (it did for other links to "scales" for example) where I had tried
    \link[sp]{sp}
and  failed here:
Debian: <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200615_213749/Debian/00check.log>
Status: 1 WARNING


So to complete the possibilities as I understand them,  I just now tried
     \link{sp}
which, as might be expected, failed here:
Debian: <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_213921/Debian/00check.log>
Status: 1 WARNING
As expected, error here was different:  "Missing  link"  as opposed to "Non-file package-anchored link"

_________


I am not sure whether I have missed a subtlety in WRE or that the peculiar circumstance
where the package, the topic, and the file name are all identical (sp) is some weird boundary case.

Without further advice, I think I am just going to remove the link to "sp".
It really is just a courtesy link to the package description for "sp".

Thanks in advance for your thoughts.

Wayne




?-----Original Message-----
From: R-package-devel <r-package-devel-bounces at r-project.org> on behalf of Georgi Boshnakov <georgi.boshnakov at manchester.ac.uk>
Date: Tuesday, June 16, 2020 at 9:27 AM
To: G?bor Cs?rdi <csardi.gabor at gmail.com>, Duncan Murdoch <murdoch.duncan at gmail.com>
Cc: List r-package-devel <r-package-devel at r-project.org>
Subject: Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)

      I think that the current behaviour is documented in WRE:

      "...There are two other forms of optional argument specified as \link[pkg]{foo} and
      \link[pkg:bar]{foo} to link to the package pkg, to files foo.html and bar.html respectively.
      These are rarely needed, perhaps to refer to not-yet-installed packages (but there the HTML
      help system will resolve the link at run time) or in the normally undesirable event that more
      than one package offers help on a topic7 (in which case the present package has precedence so
      this is only needed to refer to other packages). They are currently only used in HTML help
      (and ignored for hyperlinks in LATEX conversions of help pages), and link to the file rather
      than the topic (since there is no way to know which topics are in which files in an uninstalled
      package) ...   Because they have been frequently misused, the HTML help system looks for topic foo in package pkg
      if it does not find file foo.html."

      Unless I am missing something, it seems that it would be relatively painless to reverse the logic of the current behaviour of the help system,
      i.e. to start looking first for the topic and then for a file.

      Georgi Boshnakov

      -----Original Message-----
      From: R-package-devel <r-package-devel-bounces at r-project.org> On Behalf Of G?bor Cs?rdi
      Sent: 16 June 2020 13:44
      To: Duncan Murdoch <murdoch.duncan at gmail.com>
      Cc: List r-package-devel <r-package-devel at r-project.org>
      Subject: Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)

      On Mon, Jun 15, 2020 at 5:30 PM Duncan Murdoch <murdoch.duncan at gmail.com> wrote:

      >
      > On 15/06/2020 12:05 p.m., Martin Maechler wrote:

      > >>>>>> Duncan Murdoch   on Sun, 14 Jun 2020 07:28:03 -0400 writes:

      > >

      > >      > I agree with almost everything you wrote, except one thing:  this isn't
      > >      > newly enforced, it has been enforced since the help system began.  What
      > >      > I think is new is that there are now tests for it.  Previously those
      > >      > links just wouldn't work.

      > >

      > >      > Duncan Murdoch

      > >
      > > Yes, to all... including Duncan's agreement with G?bor.
      > >
      > > Also, Duncan M earlier did mention that he had wanted to
      > > *change* the link-to-file behavior for these cases (when he wrote
      > > most of the Rd2html source code) but somehow did not get it.

      >
      > Actually, I don't think I pushed for this change at the time (or at
      > least I didn't push much).  I just wish now that I had, because I
      > think it will be harder to do it now than it would have been then.
      >
      > Duncan

      I am not entirely sure, but maybe just documenting the current behaviour and undoing 78674 could work. With some tweaks? E.g.

      * updating R-exts to say that \link[pkg:topic]{text} will link to `topic.html` in `pkg` first (for historical reasons), and falls back to searching for `topic` in `pkg` at render time.
      * updating Rd2HTML to look for the topic and use it in the link, instead of throwing a warning, in it cannot find `topic.html`
      * removing the `R CMD check` warning for non-file links, that was added in 78674 :)

      Is there anything else?

      Gabor

      [...]

It's actually in ff/man/clone.rd, not clone.ff.rd.  There is no 
ff/man/clone.ff.rd file.

Duncan Murdoch

Best regards

Jens




On 16.06.20 22:31, G?bor Cs?rdi wrote:

This is how to look up the filename. The first "sp" is the topic name,
the second is the package name.

help("sp", "sp")[[1]]

[1] "C:/Users/csard/R/win-library/4.0/sp/help/00sp"

So you need to link to the "00sp.Rd" file:  \link[sp:00sp]{sp}

Gabor

On Tue, Jun 16, 2020 at 9:09 PM Wayne Oldford <rwoldford at uwaterloo.ca> wrote:

Hi

I got caught by this new test this week in trying to push an updated release of the loon package to CRAN.

By following this thread, I corrected my cross-references to external packages but I got stymied by
the one I hoped to give to the  "sp" package for Spatial data

_________

Here is the history:

I tried
     \link[sp:sp]{sp}
which failed here:
Debian: <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_162128/Debian/00check.log>
Status: 1 WARNING


That was meant to correct an earlier attempt (it did for other links to "scales" for example) where I had tried
    \link[sp]{sp}
and  failed here:
Debian: <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200615_213749/Debian/00check.log>
Status: 1 WARNING


So to complete the possibilities as I understand them,  I just now tried
     \link{sp}
which, as might be expected, failed here:
Debian: <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_213921/Debian/00check.log>
Status: 1 WARNING
As expected, error here was different:  "Missing  link"  as opposed to "Non-file package-anchored link"

_________


I am not sure whether I have missed a subtlety in WRE or that the peculiar circumstance
where the package, the topic, and the file name are all identical (sp) is some weird boundary case.

Without further advice, I think I am just going to remove the link to "sp".
It really is just a courtesy link to the package description for "sp".

Thanks in advance for your thoughts.

Wayne




?-----Original Message-----
From: R-package-devel <r-package-devel-bounces at r-project.org> on behalf of Georgi Boshnakov <georgi.boshnakov at manchester.ac.uk>
Date: Tuesday, June 16, 2020 at 9:27 AM
To: G?bor Cs?rdi <csardi.gabor at gmail.com>, Duncan Murdoch <murdoch.duncan at gmail.com>
Cc: List r-package-devel <r-package-devel at r-project.org>
Subject: Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)

      I think that the current behaviour is documented in WRE:

      "...There are two other forms of optional argument specified as \link[pkg]{foo} and
      \link[pkg:bar]{foo} to link to the package pkg, to files foo.html and bar.html respectively.
      These are rarely needed, perhaps to refer to not-yet-installed packages (but there the HTML
      help system will resolve the link at run time) or in the normally undesirable event that more
      than one package offers help on a topic7 (in which case the present package has precedence so
      this is only needed to refer to other packages). They are currently only used in HTML help
      (and ignored for hyperlinks in LATEX conversions of help pages), and link to the file rather
      than the topic (since there is no way to know which topics are in which files in an uninstalled
      package) ...   Because they have been frequently misused, the HTML help system looks for topic foo in package pkg
      if it does not find file foo.html."

      Unless I am missing something, it seems that it would be relatively painless to reverse the logic of the current behaviour of the help system,
      i.e. to start looking first for the topic and then for a file.

      Georgi Boshnakov

      -----Original Message-----
      From: R-package-devel <r-package-devel-bounces at r-project.org> On Behalf Of G?bor Cs?rdi
      Sent: 16 June 2020 13:44
      To: Duncan Murdoch <murdoch.duncan at gmail.com>
      Cc: List r-package-devel <r-package-devel at r-project.org>
      Subject: Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)

      On Mon, Jun 15, 2020 at 5:30 PM Duncan Murdoch <murdoch.duncan at gmail.com> wrote:

      >
      > On 15/06/2020 12:05 p.m., Martin Maechler wrote:

      > >>>>>> Duncan Murdoch   on Sun, 14 Jun 2020 07:28:03 -0400 writes:

      > >

      > >      > I agree with almost everything you wrote, except one thing:  this isn't
      > >      > newly enforced, it has been enforced since the help system began.  What
      > >      > I think is new is that there are now tests for it.  Previously those
      > >      > links just wouldn't work.

      > >

      > >      > Duncan Murdoch

      > >
      > > Yes, to all... including Duncan's agreement with G?bor.
      > >
      > > Also, Duncan M earlier did mention that he had wanted to
      > > *change* the link-to-file behavior for these cases (when he wrote
      > > most of the Rd2html source code) but somehow did not get it.

      >
      > Actually, I don't think I pushed for this change at the time (or at
      > least I didn't push much).  I just wish now that I had, because I
      > think it will be harder to do it now than it would have been then.
      >
      > Duncan

      I am not entirely sure, but maybe just documenting the current behaviour and undoing 78674 could work. With some tweaks? E.g.

      * updating R-exts to say that \link[pkg:topic]{text} will link to `topic.html` in `pkg` first (for historical reasons), and falls back to searching for `topic` in `pkg` at render time.
      * updating Rd2HTML to look for the topic and use it in the link, instead of throwing a warning, in it cannot find `topic.html`
      * removing the `R CMD check` warning for non-file links, that was added in 78674 :)

      Is there anything else?

      Gabor

      [...]

Thanks Gabor and Duncan,

It's actually in ff/man/clone.rd, not clone.ff.rd.  There is no
ff/man/clone.ff.rd file.

but there *is* clone.ff.rd in the >= 4.0.0 versions of the packages bit/bit64/ff.

Hence the check warning is a false alarm resulting from checking bit 4.0.2 (GitHub.com/truecluster) against ff 2.2-14.2 (CRAN) instead of checking it against the also submitted ff 4.0.2 (GitHub.com/truecluster).

So all I can and will do is waiting that CRAN maintainers install and check again.

Best

Jens

Duncan Murdoch

Best regards

Jens




On 16.06.20 22:31, G?bor Cs?rdi wrote:

This is how to look up the filename. The first "sp" is the topic name,
the second is the package name.

help("sp", "sp")[[1]]

[1] "C:/Users/csard/R/win-library/4.0/sp/help/00sp"

So you need to link to the "00sp.Rd" file:  \link[sp:00sp]{sp}

Gabor

On Tue, Jun 16, 2020 at 9:09 PM Wayne Oldford <rwoldford at uwaterloo.ca> wrote:

Hi

I got caught by this new test this week in trying to push an updated release of the loon package to CRAN.

By following this thread, I corrected my cross-references to external packages but I got stymied by
the one I hoped to give to the  "sp" package for Spatial data

_________

Here is the history:

I tried
     \link[sp:sp]{sp}
which failed here:
Debian: <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_162128/Debian/00check.log>
Status: 1 WARNING


That was meant to correct an earlier attempt (it did for other links to "scales" for example) where I had tried
    \link[sp]{sp}
and  failed here:
Debian: <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200615_213749/Debian/00check.log>
Status: 1 WARNING


So to complete the possibilities as I understand them,  I just now tried
     \link{sp}
which, as might be expected, failed here:
Debian: <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_213921/Debian/00check.log>
Status: 1 WARNING
As expected, error here was different:  "Missing  link"  as opposed to "Non-file package-anchored link"

_________


I am not sure whether I have missed a subtlety in WRE or that the peculiar circumstance
where the package, the topic, and the file name are all identical (sp) is some weird boundary case.

Without further advice, I think I am just going to remove the link to "sp".
It really is just a courtesy link to the package description for "sp".

Thanks in advance for your thoughts.

Wayne




?-----Original Message-----
From: R-package-devel <r-package-devel-bounces at r-project.org> on behalf of Georgi Boshnakov <georgi.boshnakov at manchester.ac.uk>
Date: Tuesday, June 16, 2020 at 9:27 AM
To: G?bor Cs?rdi <csardi.gabor at gmail.com>, Duncan Murdoch <murdoch.duncan at gmail.com>
Cc: List r-package-devel <r-package-devel at r-project.org>
Subject: Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)

      I think that the current behaviour is documented in WRE:

      "...There are two other forms of optional argument specified as \link[pkg]{foo} and
      \link[pkg:bar]{foo} to link to the package pkg, to files foo.html and bar.html respectively.
      These are rarely needed, perhaps to refer to not-yet-installed packages (but there the HTML
      help system will resolve the link at run time) or in the normally undesirable event that more
      than one package offers help on a topic7 (in which case the present package has precedence so
      this is only needed to refer to other packages). They are currently only used in HTML help
      (and ignored for hyperlinks in LATEX conversions of help pages), and link to the file rather
      than the topic (since there is no way to know which topics are in which files in an uninstalled
      package) ...   Because they have been frequently misused, the HTML help system looks for topic foo in package pkg
      if it does not find file foo.html."

      Unless I am missing something, it seems that it would be relatively painless to reverse the logic of the current behaviour of the help system,
      i.e. to start looking first for the topic and then for a file.

      Georgi Boshnakov

      -----Original Message-----
      From: R-package-devel <r-package-devel-bounces at r-project.org> On Behalf Of G?bor Cs?rdi
      Sent: 16 June 2020 13:44
      To: Duncan Murdoch <murdoch.duncan at gmail.com>
      Cc: List r-package-devel <r-package-devel at r-project.org>
      Subject: Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)

      On Mon, Jun 15, 2020 at 5:30 PM Duncan Murdoch <murdoch.duncan at gmail.com> wrote:

      >
      > On 15/06/2020 12:05 p.m., Martin Maechler wrote:

      > >>>>>> Duncan Murdoch   on Sun, 14 Jun 2020 07:28:03 -0400 writes:

      > >

      > >      > I agree with almost everything you wrote, except one thing:  this isn't
      > >      > newly enforced, it has been enforced since the help system began.  What
      > >      > I think is new is that there are now tests for it.  Previously those
      > >      > links just wouldn't work.

      > >

      > >      > Duncan Murdoch

      > >
      > > Yes, to all... including Duncan's agreement with G?bor.
      > >
      > > Also, Duncan M earlier did mention that he had wanted to
      > > *change* the link-to-file behavior for these cases (when he wrote
      > > most of the Rd2html source code) but somehow did not get it.

      >
      > Actually, I don't think I pushed for this change at the time (or at
      > least I didn't push much).  I just wish now that I had, because I
      > think it will be harder to do it now than it would have been then.
      >
      > Duncan

      I am not entirely sure, but maybe just documenting the current behaviour and undoing 78674 could work. With some tweaks? E.g.

      * updating R-exts to say that \link[pkg:topic]{text} will link to `topic.html` in `pkg` first (for historical reasons), and falls back to searching for `topic` in `pkg` at render time.
      * updating Rd2HTML to look for the topic and use it in the link, instead of throwing a warning, in it cannot find `topic.html`
      * removing the `R CMD check` warning for non-file links, that was added in 78674 :)

      Is there anything else?

      Gabor

      [...]

Thanks Gabor and Duncan,

It's actually in ff/man/clone.rd, not clone.ff.rd.  There is no
ff/man/clone.ff.rd file.

but there *is* clone.ff.rd in the >= 4.0.0 versions of the packages bit/bit64/ff.

Hence the check warning is a false alarm resulting from checking bit 4.0.2 (GitHub.com/truecluster) against ff 2.2-14.2 (CRAN) instead of checking it against the also submitted ff 4.0.2 (GitHub.com/truecluster).

So all I can and will do is waiting that CRAN maintainers install and check again.

Best

Jens

Duncan Murdoch

Best regards

Jens




On 16.06.20 22:31, G?bor Cs?rdi wrote:

This is how to look up the filename. The first "sp" is the topic name,
the second is the package name.

help("sp", "sp")[[1]]

[1] "C:/Users/csard/R/win-library/4.0/sp/help/00sp"

So you need to link to the "00sp.Rd" file:  \link[sp:00sp]{sp}

Gabor

On Tue, Jun 16, 2020 at 9:09 PM Wayne Oldford <rwoldford at uwaterloo.ca> wrote:

Hi

I got caught by this new test this week in trying to push an updated release of the loon package to CRAN.

By following this thread, I corrected my cross-references to external packages but I got stymied by
the one I hoped to give to the  "sp" package for Spatial data

_________

Here is the history:

I tried
      \link[sp:sp]{sp}
which failed here:
Debian: <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_162128/Debian/00check.log>
Status: 1 WARNING


That was meant to correct an earlier attempt (it did for other links to "scales" for example) where I had tried
     \link[sp]{sp}
and  failed here:
Debian: <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200615_213749/Debian/00check.log>
Status: 1 WARNING


So to complete the possibilities as I understand them,  I just now tried
      \link{sp}
which, as might be expected, failed here:
Debian: <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_213921/Debian/00check.log>
Status: 1 WARNING
As expected, error here was different:  "Missing  link"  as opposed to "Non-file package-anchored link"

_________


I am not sure whether I have missed a subtlety in WRE or that the peculiar circumstance
where the package, the topic, and the file name are all identical (sp) is some weird boundary case.

Without further advice, I think I am just going to remove the link to "sp".
It really is just a courtesy link to the package description for "sp".

Thanks in advance for your thoughts.

Wayne




?-----Original Message-----
From: R-package-devel <r-package-devel-bounces at r-project.org> on behalf of Georgi Boshnakov <georgi.boshnakov at manchester.ac.uk>
Date: Tuesday, June 16, 2020 at 9:27 AM
To: G?bor Cs?rdi <csardi.gabor at gmail.com>, Duncan Murdoch <murdoch.duncan at gmail.com>
Cc: List r-package-devel <r-package-devel at r-project.org>
Subject: Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)

       I think that the current behaviour is documented in WRE:

       "...There are two other forms of optional argument specified as \link[pkg]{foo} and
       \link[pkg:bar]{foo} to link to the package pkg, to files foo.html and bar.html respectively.
       These are rarely needed, perhaps to refer to not-yet-installed packages (but there the HTML
       help system will resolve the link at run time) or in the normally undesirable event that more
       than one package offers help on a topic7 (in which case the present package has precedence so
       this is only needed to refer to other packages). They are currently only used in HTML help
       (and ignored for hyperlinks in LATEX conversions of help pages), and link to the file rather
       than the topic (since there is no way to know which topics are in which files in an uninstalled
       package) ...   Because they have been frequently misused, the HTML help system looks for topic foo in package pkg
       if it does not find file foo.html."

       Unless I am missing something, it seems that it would be relatively painless to reverse the logic of the current behaviour of the help system,
       i.e. to start looking first for the topic and then for a file.

       Georgi Boshnakov

       -----Original Message-----
       From: R-package-devel <r-package-devel-bounces at r-project.org> On Behalf Of G?bor Cs?rdi
       Sent: 16 June 2020 13:44
       To: Duncan Murdoch <murdoch.duncan at gmail.com>
       Cc: List r-package-devel <r-package-devel at r-project.org>
       Subject: Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)

       On Mon, Jun 15, 2020 at 5:30 PM Duncan Murdoch <murdoch.duncan at gmail.com> wrote:

       >
       > On 15/06/2020 12:05 p.m., Martin Maechler wrote:

       > >>>>>> Duncan Murdoch   on Sun, 14 Jun 2020 07:28:03 -0400 writes:

       > >

       > >      > I agree with almost everything you wrote, except one thing:  this isn't
       > >      > newly enforced, it has been enforced since the help system began.  What
       > >      > I think is new is that there are now tests for it.  Previously those
       > >      > links just wouldn't work.

       > >

       > >      > Duncan Murdoch

       > >
       > > Yes, to all... including Duncan's agreement with G?bor.
       > >
       > > Also, Duncan M earlier did mention that he had wanted to
       > > *change* the link-to-file behavior for these cases (when he wrote
       > > most of the Rd2html source code) but somehow did not get it.

       >
       > Actually, I don't think I pushed for this change at the time (or at
       > least I didn't push much).  I just wish now that I had, because I
       > think it will be harder to do it now than it would have been then.
       >
       > Duncan

       I am not entirely sure, but maybe just documenting the current behaviour and undoing 78674 could work. With some tweaks? E.g.

       * updating R-exts to say that \link[pkg:topic]{text} will link to `topic.html` in `pkg` first (for historical reasons), and falls back to searching for `topic` in `pkg` at render time.
       * updating Rd2HTML to look for the topic and use it in the link, instead of throwing a warning, in it cannot find `topic.html`
       * removing the `R CMD check` warning for non-file links, that was added in 78674 :)

       Is there anything else?

       Gabor

       [...]

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.

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.

Gesendet: Donnerstag, 02. Juli 2020 um 15:23 Uhr
Von: "Duncan Murdoch" <murdoch.duncan at gmail.com>
An: "Dr. Jens Oehlschl?gel" <jens.oehlschlaegel at truecluster.com>, r-package-devel at 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

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.

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 at gmail.com>
An: "Dr. Jens Oehlschl?gel" <jens.oehlschlaegel at truecluster.com>, r-package-devel at 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