Dear Axel,
Thanks for the CC, private email was an error.
On 15/06/13 12:14, Axel Beckert wrote:
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.
I see your point now. Ok agree on the fact that this should probably be
more general. The only slight difference with iceape is that it's not
just a browser but more of a 'suite' which was my initial reason to file
this as bug. But I see that after discussion that would be nitpicking.
So do close the bug and thanks for the opinion exchange and taking time
to answer.
Lorenzo
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-de...@lists.debian.org mailing list.
Regards, Axel
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
