Bug#172436: BROWSER and sensible-browser standardization
- To: email@example.com
- Subject: Bug#172436: BROWSER and sensible-browser standardization
- From: Jonathan Nieder <firstname.lastname@example.org>
- Date: Wed, 28 Sep 2011 05:55:13 -0500
- Message-id: <20110928105512.GA28823@elie>
- Reply-to: Jonathan Nieder <email@example.com>, firstname.lastname@example.org
- In-reply-to: <email@example.com>
- References: <firstname.lastname@example.org> <20080428100918.GA29043@pcbcn10.phys.rug.nl> <20080428130801.GA7694@ouaza.com> <20080428210719.GB13174@pcbcn10.phys.rug.nl> <20080428222303.GA27900@roeckx.be> <20080429062425.GA3210@ouaza.com> <email@example.com>
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?