Bug#712299: iceape: Iceape becomes default x-www-browser

Axel Beckert abe at debian.org
Sat Jun 15 10:14:02 UTC 2013


Hi Lorenzo,

I'm Cc'ing the bug-report again as I think this discussion should be
public.

On Sat, Jun 15, 2013 at 11:34:42AM +0200, Lorenzo Sutton wrote:
> > There is such a mechanism. See the update-alternatives(8) man page.
> 
> I'm aware of the update-alternatives.
> What I'm saying is that it would be more friendly if when a
> (x-www-browser) browser is already present and selected installing
> another one (in this case iceape) wouldn't necessarily change the
> current x-www-browser.

In my humble opinion, you can't expect that the first web browser ever
installed on a system stays the default forever.

But besides that, the administrator as well as the user do have this
choice. They just have to state it once explicitly. (They're not asked
automatically, though. They have to take action theirselves.)
Otherwise the packages will continue to choose the default.

The details:

update-alternatives supports not changing x-www-browser upon
installation of an alternative with higher priority. I mentioned it
briefly in my initial reply. I'll make an example more specific on
that topic below.

> In my case iceweasel had already been installed and was of course
> the x-www-browser.
> 
> Ultimately what I mean is that the user should have the choice to
> decide what has higher priority, and not the package.

As administrator you have to explicitly choose any browser in "manual
mode" (i.e. the user's choice is honoured) instead of "auto mode"
(i.e. the packages decide which seems the best), as I did here:

# update-alternatives --config x-www-browser 
There are 13 choices for the alternative x-www-browser (providing
/usr/bin/x-www-browser).

  Selection    Path                   Priority   Status
------------------------------------------------------------
  0            /usr/bin/opera          200       auto mode
  1            /usr/bin/chromium       40        manual mode
* 2            /usr/bin/conkeror       20        manual mode
  3            /usr/bin/dillo          50        manual mode
  4            /usr/bin/iceweasel      70        manual mode
  5            /usr/bin/luakit         10        manual mode
  6            /usr/bin/midori         50        manual mode
  7            /usr/bin/netsurf        100       manual mode
  8            /usr/bin/opera          200       manual mode
  9            /usr/bin/surf           30        manual mode
  10           /usr/bin/uzbl-browser   10        manual mode
  11           /usr/bin/vimprobable2   20        manual mode
  12           /usr/bin/xlinks2        69        manual mode
  13           /usr/bin/xxxterm        50        manual mode

Press enter to keep the current choice[*], or type selection number: 
[...]

In my case, the default browser by package choice would be the
non-free opera package (priority 200), but I prefer to have conkeror
as default browser system-wide. So I've chosen option 2 (conkeror in
manual mode). Now, conkeror stays x-www-browser even if I'd install a
browser which says that it has priority 300.

Besides that, each user can still override the default browser per user
instead of using the system-wide setting via x-www-browser by two ways:

1) In case of using a desktop environment, usually the desktop
   environment allows to change the default web browser for the
   current user. (This may depend on the desktop environment -- at
   least GNOME offered to configure that the last time I checked.)

2) For users without a full-blown desktop environment there's also
   /usr/bin/sensible-browser (of the package sensible-utils) which, in
   addition to the above, checks if the environment variable $BROWSER
   is set as well if GNOME is running, in which case it prefers
   gnome-www-browser over x-www-browser. It can even run text-mode
   based browsers like lynx and w3m in a terminal if prefered by the
   user.

In my humble opinion, those three places to change the default web
browser together allow full and fine granulated control over which
alternatives is used in which situation for each, the administrator,
for the desktop environment user as well as for the commandline user.

If you think, that all is still not a good enough solution, i.e.
because they're not asked without taking action theirselves, I would
recommend you to file a more general bug instead of this one against a
single web browser which can't and won't change the overall situation
and infrastructure.

update-alternatives is part of the dpkg package, so I think that
filing a bug report against dpkg would be a proper starting point. I
though suspect that this would be a more general discussion, maybe
held on the debian-devel at lists.debian.org mailing list.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5



More information about the pkg-mozilla-maintainers mailing list