[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

	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: