removing wslview from Ubuntu-only computers?

[Little Girl]

Hey there,

Keith wrote:
>Little Girl wrote:

>Gimp-help-en is dependent on the virtual package, www-browser, not
>wslu specifically. Installing another package from this list:
>$ apt-cache search www-browser --names-only
>will satisfy that dependency.

The wslu package is on that list, which may explain why it's choosing
it:

firefox - Transitional package - firefox -> firefox snap
w3m - WWW browsable pager with excellent tables/frames support
chromium-browser - Transitional package - chromium-browser -> chromium snap
dillo - Small and fast web browser
edbrowse - /bin/ed-alike webbrowser written in C
elinks - advanced text-mode WWW browser
epiphany-browser - Intuitive GNOME web browser
falkon - lightweight web browser based on Qt WebEngine
hv3 - Lightweight web browser
konqueror - advanced file manager, web browser and document viewer
links - Web browser running in text mode
links2 - Web browser running in both graphics and text mode
luakit - fast and small web browser extensible by Lua
lynx - classic non-graphical (text-mode) web browser
netrik - text mode WWW browser with vi like keybindings
netsurf-fb - small web browser with CSS support for framebuffers
netsurf-gtk - small web browser with CSS support for GTK
qutebrowser - Keyboard-driven, vim-like browser based on PyQt5
sugar-browse-activity - Sugar Learning Platform - web browsing activity
surf - Simple web browser by suckless community
wslu - collection of utilities for the Windows 10 Linux Subsystem
xemacs21-mule - highly customizable text editor -- Mule binary
xemacs21-mule-canna-wnn - highly customizable text editor -- Mule binary compiled with Canna and Wnn
xemacs21-nomule - highly customizable text editor -- Non-mule binary

>Either a text-based or lightweight gui web browser would be adequate
>for viewing html documentation like that found in the gimp-help-en
>package. If you are using the Firefox snap, you could install the
>firefox deb which would also solve the problem. You can then remove
>wslu.

You and Oliver Grawert keep saying that, but are you both sure? The
description for the "firefox" package in the "Details" tab of my
package manager says:

	This is a transitional dummy package. It can safely be
	removed.

	firefox is now replaced by the firefox snap.

	Canonical provides critical updates for firefox until Sat Oct
	21 2023.

My understanding of that is that it isn't intended to be installed
and left in place at all and that the Firefox Snap replaces it. Since
the Firefox Snap is already installed by default, it's already been
replaced before it even had a chance to exist. Since the repository
information here says that it's been replaced and that you can safely
remove it, it stands to reason that it isn't actually used.

A friend of mine believes that gvfs is the package that's needed to
solve this issue. He poked around in the /usr/share/gimp/2.0/help/en
subdirectory to see why, when you click "Help" in GIMP, Firefox pops
up with a can't-find-file error message even though the index.html
file existed. Then it hit him that because Snaps are sandboxed, the
Firefox Snap is unable to access that external file.  He messed
around with wslu and convinced himself that the bad behavior couldn't
be healed and that other packages provided www-browser to display
help content.

That didn't address GIMP needing the gimp-help-en file and not being
able to secure it without inviting the unwelcome wslu package to come
along for the ride.  But GIMP supports the manual/help being read
online. He determined that you need gvfs to run that dance, so he
installed that (without the "firefox" package being installed and
with just the Firefox Snap in place).

He says this works because the hybrid system created by the
developers has failed to account for the inside looking out and the
outside looking in. With the gvfs package in place,
check-language-support sees the en language pack and doesn't care if
it's in use within the program or or if the Help is playing in the
browser.

So, I'm still left unsure of what to do next. I have no idea which of
you is right and am loathe to experiment with unknowns on an LTFS
release, so I'm in limbo and am still very much dealing with refusing
to allow the wslu package to be installed on a daily basis. It's all
very strange.

>Well, its not that Firefox is provided as a snap. It's that the
>firefox transitional deb package isn't present on fresh
>installations like it is for upgrades so there's no default package
>that provides the www-browser dependency.

You seem to have contradicted yourself. The transitional package is
only necessary because Firefox has been provided as a non-traditional
container application instead of as a traditional package, which
solidly puts the responsibility on the provision of Firefox as a
Snap.

>Btw, if snap was never a thing and Ubuntu chose instead to start
>using flatpaks or even appimages for containerized applications,
>you'd run into the same problem. I don't believe it's specific to
>snap package management.

I'm good with that, since my above statement would fit either of
these scenarios equally well regardless of which containerized
application is being referenced.

-- 
Little Girl

There is no spoon.