Re: introduction of x-www-browser virtual package
On Fri, Jan 11, 2019 at 07:01:59PM +0000, Simon McVittie wrote:
To facilitate that, I'd say the definition of that virtual package should
include a desktop file with at least text/html, x-scheme-handler/http
and x-scheme-handler/https in its MimeType list (I think that's what
makes it eligible to be chosen as a per-user preferred web browser),
and not just participation in the x-www-browser alternative.
Yes that's a good idea. You may be interested in something else I'm
(slowly) working on: I would like to encode such requirements of virtual
packages. The first step was to rewrite the virtual package list in a
structured format, which is now done. I hope to extend the schema to
support things like "(should|must|etc) implement alternative /path". The
next step would be to write things like lintian tests, UDD queries etc
to use that information. And the step after that would be collecting
other useful properties, such as these that you describe, that could be
useful encoded.
If the depending package is part of LXDE and is opening a URL, it could
short-circuit the "what desktop are you?" logic and depend directly
on something (anything) that implements freedesktop URL handling and
has dependencies that would normally be installed by LXDE anyway. For
example, if LXDE depends on GLib already, then libglib2.0-bin (for
"Exec=gio open %u") would be uncontroversial.
Yes. And that's a good specific suggestion for this case. I wasn't too
concerned about dependency "bloat" (although the LXDE maintainers might
be) so much as resolving the issue of ensuring a browser was installed.
Unfortunately I don't think there's a way to express "open the preferred
web browser to its default start page" as a URL to be opened.
That's an interesting problem to look at.
Yes, if you want to depend on "some arbitrary browser" then you need a
virtual package.
I wasn't making that decision myself, so much as following it through
from the decision to put x-www-browser in the .desktop file. It's
definitely a good idea to revisit that.
However, I agree with Jeremy that "some arbitrary browser" is unlikely
to be the UX anyone is actually looking for, and the browser that is
preferred by the desktop environment's metapackage (which appears to be
Firefox) would lead to more predictable behaviour. We're making an OS
distribution here, not just a pile of packages, so it seems appropriate
to make a choice, and back it up with some appropriate Recommends.
If the LXDE maintainers simply specify firefox in the .desktop and
Recommend on firefox-esr, it would be possible to install lxpanel
without firefox (or, remove firefox later) and have a non-functioning
icon on the toolbar, which is the situation I'm trying to fix now.
The .desktop file currently specified Exec= but unfortunately, lxpanel
displays an icon for the shortcut even if it is altered to TryExec= and
the path is not satisfied. It reports "invalid desktop file
lxde-x-www-browser.desktop", which could be improved.
(Currently their browser dependency is in Suggests, I think bumping it
to Recommends would be a small improvement)
As an additional data-point, I'm not sure if lxpanel is maintained
upstream any more. https://git.lxde.org/gitweb/ shows a repository for
the Debian packaging (last modified nearly 2 years ago; and the version
of lxpanel in sid is the same as in stretch) but no upstream repository,
there is an lxqt-panel repository. I was under the impression the LXDE
people were moving to LXQT, but I have no idea how far they've got on
that transition (and whether Debian has caught up). The prospect of
tweaking a package dependency to resolve this doesn't seem too bad;
hacking on the program itself to alter it's behaviour around
Exec=/TryExec= more awkward.
For what it's worth, GNOME as packaged in Debian adjusts
the default MIME type and URI scheme handler preference in
/usr/share/applications/gnome-mimeapps.list to prefer firefox-esr or
firefox over other browsers, and adds firefox-esr as a predefined
"favourite app" in GNOME Shell using a GSettings override. In both
cases, this can be overridden by user configuration. GNOME upstream
would normally have used Epiphany (aka "Web", GNOME's own web browser),
in both cases, but the Debian GNOME team has chosen to prefer Firefox
because multi-year security support for WebKit-GTK+ and Epiphany is not
feasible to do within the constraints of Debian stable release policies.
That's a very sensible decision for GNOME-in-Debian. I think it would be
wise of all the DEs in Debian (with possibly the notable exception of
KDE) aligned accordingly.
I'll take this to pkg-lxde-maintainers@alioth-lists.debian.net as the
next step.
Thanks,
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.
Reply to: