The X USE Flag for R currently controls whether R is build with X11-Support, meaning plotting to an X-Surface. At the same time, the USE-Flag is also made control whether xdg-open will be pulled in so that help.start( ) will open http://127.0.0.1:21671/doc/html/index.html. It would be preferable if those two unrelated functionalities could be split out into two distinct use flags. Optimally, if the build process allows for it, the whole "Local Help served by R over HTTP" part could be disabled (we can use /usr/share/doc like for every other program), so this would perfectly well work out as two USE Flags X - X11( );-Driver support http - Stub-(I hope!)-HTTP-Server support for serving the help over HTTP, accompanied by xdg-open to open the URL with the preffered browser.
> (we can use /usr/share/doc like for every other program) This was nonsense. The on-line help would still be available. Also, I only learned that the HTTP function is actually used to generate the help pages on the fly - not serving them from the disk. Regardless, the xdg-open dependency should relate to the HTTP function and not be part of the USE-Flag which controls whether the X11-driver is built.
Please don't do that.
(In reply to comment #2) > Please don't do that. Please don't do what? I'd like to remind you that it's not appropriate for you to remove CC's or change a bug's other attributes if you have no business doing so. Further, plase refrain from making incomprehensible comments absent justification or context.
FYI: I'd added Denis to CC because I opened this bug on his behalf after talking to him on IRC.
I'm sure you remember this bug from a decade ago... Looking at the ebuild, all that's happening is, if use X; then export R_BROWSER="$(type -p xdg-open)" export R_PDFVIEWER="$(type -p xdg-open)" fi which explicitly sets the default browser and PDF viewer to xdg-open. No features are truly enabled or disabled as a result. And in fact, if those two variables are left unset, then R will try to guess your browser and PDF viewer (m4/R.m4) at build time: AC_PATH_PROGS(R_BROWSER, [firefox mozilla galeon opera xdg-open kfmclient gnome-moz-remote open]) AC_PATH_PROGS(R_PDFVIEWER, [${R_PDFVIEWER} acroread acroread4 xdg-open evince xpdf gv gnome-gv ggv okular kpdf open gpdf kghostview] ...and xdg-open appears in the list. What do you think should be done here, if you still care? I'm not an R user, but looking at it fresh, I think we could, * (Upstream) Update those two lists to put xdg-open first * (Upstream) Modernize both lists * (Upstream) Add browser fallbacks for a few text-based browsers * Drop the "if" statement above from the ebuild entirely. Otherwise, frankly, I think the current behavior is not so bad. All it's doing is setting the best defaults (xdg-open) possible. It's predictable, and the user can still override them.
I haven't used R for a long time and I haven't used X for an even longer time (so closing the bug would be fine with me), but I don't see your point. How and if R chooses to display the help is/was not my concern (and I don't disagree with any of your suggestions pertaining to the opening of the help). My problem was only that the capabilities for - Displaying Help (with xdg-open, browser, or whatever) and - Plotting to an X11 Surface are both controlled by a single USE flag, although they are unrelated.
(In reply to Cedric Sodhi from comment #6) > > My problem was only that the capabilities for > > - Displaying Help (with xdg-open, browser, or whatever) and > - Plotting to an X11 Surface > > are both controlled by a single USE flag, although they are unrelated. Maybe this is something that changed in the meantime? In the R-4.2.1 ebuild, USE=X doesn't actually affect the help system at all. All it does (with respect to the help) is set the default value of R_BROWSER to xdg-open. I've just built R-4.2.1 on my machine without USE=X, and help.start() immediately opens firefox.
As I read the ebuild it DOES pull in xdg-utils, though (which is likely motivated by the `if`).
(In reply to Cedric Sodhi from comment #8) > As I read the ebuild it DOES pull in xdg-utils, though (which is likely > motivated by the `if`). Right, but only so that it can set xdg-open as your browser and PDF viewer. We could probably drop that dependency and this clause, if use X; then export R_BROWSER="$(type -p xdg-open)" export R_PDFVIEWER="$(type -p xdg-open)" fi if the R build system was a bit smarter about finding your preferred tools. In particular, if it preferred xdg-open over, say, firefox and acroread.
(In reply to Michael Orlitzky from comment #9) > > if the R build system was a bit smarter about finding your preferred tools. > In particular, if it preferred xdg-open over, say, firefox and acroread. Reported upstream at, https://bugs.r-project.org/show_bug.cgi?id=18403
I'm afraid we are talking in circles here... I _do_ concur with your interpretation of xdg-open and the browser, but my point is that it is controlled by the _SAME_ USE-flag as the support for plotting graphs to an X11 surface (namely, the "X" USE flag). _That_ is what I suggest is the (downstream) bug. If what I say doesn't make any sense, feel free to ignore.
(In reply to Cedric Sodhi from comment #11) > I'm afraid we are talking in circles here... I _do_ concur with your > interpretation of xdg-open and the browser, but my point is that it is > controlled by the _SAME_ USE-flag as the support for plotting graphs to an > X11 surface (namely, the "X" USE flag). > > _That_ is what I suggest is the (downstream) bug. > > If what I say doesn't make any sense, feel free to ignore. What you're saying does make sense. If upstream accepts my first patch, I'll delete, if use X; then export R_BROWSER="$(type -p xdg-open)" export R_PDFVIEWER="$(type -p xdg-open)" fi and (and maybe drop the xdg-utils dependency) and then USE=X will no longer be involved in any way. That should make everyone happy: * No more abuse of USE=X to control the default browser * People with xdg-utils installed get a sensible default * People without xdg-utils installed get whatever the R build system guesses
Upstream merged my patches, so this could be available as soon as R-4.2.2.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5a44f9d1cc382f7533212bd2d2662f3dcca3ad4b commit 5a44f9d1cc382f7533212bd2d2662f3dcca3ad4b Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2022-11-22 19:21:34 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2022-11-22 21:40:45 +0000 dev-lang/R: add 4.2.2 My upstream patches to the R_BROWSER and R_PDFVIEWER search order didn't land in this release, but we're already running eautoreconf, so we might as well include them. This lets us drop the dependency on xdg-utils, and remove the stanza (conditional on USE=X) that sets the default browser and viewer to xdg-open. We are also able to drop a patch to the test suite that was merged upstream. Closes: https://bugs.gentoo.org/458176 Closes: https://bugs.gentoo.org/879863 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> dev-lang/R/Manifest | 1 + dev-lang/R/R-4.2.2.ebuild | 246 +++++++++++++++++++++++ dev-lang/R/files/R-4.2.2-browser-pdf-prefs.patch | 95 +++++++++ 3 files changed, 342 insertions(+)
