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

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to