On Fri, Aug 17, 2012 at 11:07 AM, Ivan Shmakov <oneingray@gmail.com> wrote:
> Abstract
>
> The non-data packages currently having an absolute dependency on
> hicolor-icon-theme should consider downgrading it to Recommends:
> at the least. The list, and the explanation, are below.
>
>
> Chapter I
> imagemagick
>
> Recently, Depends: hicolor-icon-theme was added to the
> imagemagick's control file, which triggered my curiosity: does
> it provide something that wasn't needed (or was missed) by the
> previous versions of the package, but is strictly necessary to
> run the newer ones?
>
> Indeed, it doesn't.
>
> To prove it, I've made a trivial control file for
> equivs-build(1):


first thanks for this but a bug report to imagemagick will be
morehelpful. Secondly I add depends on hicolor-icon-theme in order to
use
the trigger on it for registering icon-cache.

Do you have checked if display on menu show the icons ?

Did you check if you install hicolor-icon-theme after icon cache
trigger run correctly on the imagemagick icons ?

[...]
> Well, it doesn't seem suspicious for anything *-icon-* and
> *-data to depend on an icon theme, but what about the rest?
>
> For a start, I've omitted rabbitvcs-core and viridian, and
> considered d-feet, flush, openteacher, perlpanel, and synaptic.
> 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?)

Yes lack of icon. it the same on the gnome menu if I remove the

For imagemagick this will be solved in a future release with a non X
depend on the base version. But it is really too late on freeze.

Bastien
>
>
> Conclusion
>
> 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.)
>
> As for the other packages considered, my suggestion would be to
> downgrade the dependencies to Recommends: (or, for openteacher,
> to Suggests:, if it's indeed unaffected.)
>
> Unless there'd be any objections, I'll consider filing a bug
> against imagemagick, and perhaps the other aforementioned
> packages as well.
>
>
> Post Scriptum
>
> Curiously enough, the only “application� package having a
> Recommends: dependency on hicolor-icon-theme is cheese.
>
> --
> FSF associate member #7257 http://sf-day.org/
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: http://lists.debian.org/86ehn551jr.fsf@gray.siamics.net
>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAE2SPAbgkUdj7AcjBGKS+Y3yBita2Jt4j2Z792OXaAXFZoe6S A@mail.gmail.com">http://lists.debian.org/CAE2SPAbgkUdj7AcjBGKS+Y3yBita2Jt4j2Z792OXaAXFZoe6S A@mail.gmail.com

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 502E6D3E.6010700@debian.org">http://lists.debian.org/502E6D3E.6010700@debian.org

>>>>> 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/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 86ipcg1yzs.fsf@gray.siamics.net">http://lists.debian.org/86ipcg1yzs.fsf@gray.siamics.net