Hi, 在 2023-01-17星期二的 13:56 +0900,John Crawley写道: > Package: papirus-icon-theme > Version: 20210201-1 > Severity: normal > X-Debbugs-Cc: j...@bunsenlabs.org > > Dear Maintainer, > > * What led up to the situation? > On a Debian Bullseye system without librsvg2-common installed, Papirus icons > were not correctly displayed. > > * What exactly did you do that was effective? > Install librsvg2-common. > > * What was the outcome of this action? > Icons were correctly displayed. > > ( This might have been the underlying issue in bug #982901 ) > > Because it is a dependency of many other packages, librsvg2-common will > often already be installed, hiding the dependency from papirus-icon-theme. > > gnome-icon-theme depends on, and adwaita-icon-theme recommends librsvg2- > common. > As a theme using svg icons, papirus-icon-theme could be expected to depend > on, or at least recommend, librsvg2-common too.
Logically I very much dislike the idea of adding dependency from an icon theme to some package that provides the SVG parsing functionality (e.g., librsvg2- common). Such dependency should be handled by whoever *consumes* SVG icons (e.g., spacefm), not the package that *provides* SVG icons. Why should an icon theme package know that some random desktop software will need a "librsvg2- common" to parse SVG correctly? What if that desktop software actually needs some other SVG parsing library (e.g., libqt5svg5) ? Why *should* I know that? This does not make any sense. Back to actual packaging: I could add a recommendation to librsvg2-common, but I will definitely not opt to go for a hard dependency. I will make the upload shortly. Thanks, Boyuan Yang
signature.asc
Description: This is a digitally signed message part