Re: Depends: hicolor-icon-theme: shouldn't it be Recommends: instead?
>>>>> Simon McVittie <smcv@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/
Reply to: