Control: severity -1 important
Control: block 1148038 by -1
On Tue, 24 Sep 2024 at 00:16:55 +0900, Hideki Yamane wrote:
On Fri, 20 Oct 2023 14:11:22 +0100 Simon McVittie <[email protected]> wrote:
unifont-bin depends on libwx-perl, which as mentioned in #1054146 is
unmaintained upstream and only minimally maintained in Debian.
debian-installer build-depends on unifont-bin, which brings libwx-perl
into the critical path for being able to build d-i.
This is now a practical problem again because libwx-perl depends on
libwxgtk-webview3.2-1t64, which needs to be removed from s390x and other
big-endian architectures as a result of WebKitGTK dropping the ability
to run on big-endian platforms (<https://bugs.debian.org/1148038>).
unifont-bin doesn't use Wx::WebView itself, but libwx-perl is a single
package providing bindings for all functionality of wxwidgets, including
the web view, so it might not be straightforward to separate.
libwx-perl also has an unrelated RC bug, <https://bugs.debian.org/1133539>.
Isn't it enough to split unifont-viewer from unifont-bin, then?
I'm not sure that I understand the purpose of unifont-viewer. Who would
want to run it? What is it useful for?
If it's sufficiently useful to justify the addition of a new binary
package, then the new binary package will need to be either
Architecture: all (and only installable on little-endian systems), or
only built on little-endian architectures.
Or perhaps the Depends: libwx-perl could be dropped to a Suggests, if we
expect that users of unifont-bin (which seem to be mainly
build-dependencies for packages like console-setup and debian-installer)
will only rarely run unifont-viewer?
Or, if unifont-viewer is only rarely useful, it could be removed from
the binary package completely. It looks as though it would probably
still be possible to unpack the source package and run it from there, if
it becomes useful during development.
smcv
