>>>>> Simon McVittie <s...@debian.org> writes: […]
> 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. ACK, thanks for the explanation, and apologies for a “false alarm.” (But why the other “theme” packages depend on it, BTW?) Now, I wonder, could its Description: be amended so to explain its function in more detail? Stating that it's “the default fallback theme” doesn't tell quite much to me, for instance. Consider, e. g. (though the wording is flaky a bit): Description: FreeDesktop.org default fallback theme infrastructure This package contains the necessary infrastructure for the applications to install their theme-neutral icons for the implementations of the Freedesktop.org Icon Theme specification to use. It provides the respective directory layout, an index file, and a script to start gtk-update-icon-cache(1) as necessary. . This package is not an icon theme per se as it contains no icons of its own. The "hicolor" name was hardcoded into an older version of a major desktop environment and is retained for historical reasons. > 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. Thus, its function also implies a couple of Shell scripts below /var/lib/dpkg/info/, too. (Which are simple enough to not worry about, though.) […] > 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? At the very least, it now doesn't bother me much more than having libmysqlclient18 installed on my MX'es running exim4-daemon-heavy (given that I never had to use MySQL with it specifically.) Still, using Depends: to depend on a (otherwise optional) .postinst script doesn't seem quite right to me. (And I'm pretty sure that dependencies of such a kind are generally Recommends: ones in Debian.) -- FSF associate member #7257 http://sf-day.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/86ipcg1yzs....@gray.siamics.net