Re: Depends: hicolor-icon-theme: shouldn't it be Recommends: instead?
On 17/08/12 10:07, Ivan Shmakov wrote:
> Unsurprisingly, all of them were able to install and run, but
> while openteacher is seemingly unaffected by the absence of the
> data in question, the rest have had obvious issues: almost all
> of the icons were absent, resulting in blank space on the GUI,
> missing controls, and warnings to stderr (stdout?)
hicolor-icon-theme is really the infrastructure for a theme, rather than
*being* a theme: it does not contain any icons of its own. It represents
the fallback icon theme for all desktops that use freedesktop.org themes
(GNOME, KDE, XFCE, etc.). The name "hicolor" is for historical reasons -
it was the default icon theme hard-coded into old versions of one of the
major desktop environments (KDE 2 or 3, I think?) and it stuck.
Its purpose is to be the theme into which applications install their
"theme-neutral" icons: anything that displays a themeable icon should
search for it in the configured theme, and then fall back to hicolor.
Its only file outside /usr/share/doc is metadata describing the
directories it provides (index.theme, 24K), and its postinst and dpkg
trigger maintain a Gtk icon cache for icons added to it by applications.
For instance, d-feet installs
/usr/share/icons/hicolor/24x24/apps/d-feet-icon.png, among others. In
principle, the author of an icon theme could ship their own
d-feet-icon.png (e.g. .../gnome/.../apps/d-feet-icon.png for the GNOME 3
icon theme) which would take precedence. If they don't, the menu
displaying the icon should automatically fall back to the
"theme-neutral" version in hicolor, provided by d-feet itself. The
result is that icon themes or desktop environments can re-theme
applications' icons if they want to, but any applications that they
don't cover will get a reasonable theme-neutral fallback icon.
> Since there're (as it seems) virtually no issues with running
> imagemagick without a “real” hicolor-icon-theme installed, my
> suggestion would be to downgrade the dependency to Suggests: (or
> Recommends:, if there's some point I've missed.)
Turning this round: what benefit would we derive from avoiding
depedencies on hicolor-icon-theme? It doesn't depend on anything, and
contains exactly one file (and a bunch of empty directories) outside
/usr/share/doc.
I don't think "we could potentially save 24K on those rare systems that
have certain specific X apps, but no GUI menu" is a very compelling
reason to change packages' dependencies?
S
Reply to: