Hi Russ,
This question came up recently on the git mailing list in the context
of "git web--browse" (a backend used by git instaweb and some other
commands). It would have been nice to have clear advice in Debian
policy to guide what we should do.
>From the point of view of improving upstream programs, I think the
best Debian can do is:
1. For desktop apps, recommend unconditional use of xdg-open.
2. For everyone else:
a. Clearly specify the semantics of the BROWSER variable to the
extent that there is wide consensus about it or a strong
rationale (in other words, clearly indicating the murky bits
and leaving them unspecified).
b. Encourage use of x-www-browser and www-browser as defaults
when BROWSER is unset (so upstreams' use of "firefox" and
"lynx" can be made configurable at compile time).
c. For non-desktop apps lacking support for the BROWSER variable,
recommend unconditional use of xdg-open (for the same reason).
This should result in a reasonable user experience, as long as:
i. xdg-open and sensible-browser make settings like
BROWSER=firefox:lynx work as intended and take precedence over
any system-wide settings.
ii. xdg-open works well and respects the current desktop's system-wide
and per-user "preferred browser" configuration.
iii. When xdg-open is installed, some xdg-open workalike registers
itself through the alternatives system as a possible
implementation of the x-www-browser command.
Unfortunately at least gnome-open seems to violate (i). So for policy
there are at least two options: we could specify everything except (i),
and leave whether to implement (i) to the desktop maintainers, or
we could specify (i), too, and create consensus e.g. by proposing a
patch to libgnome.
Both sound like work. :( I guess I'm tempted to specify everything
except (i) and mention (i) as "arguably a bug" to get past the logjam.
What do you think?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
