Bug#831828: libgtk2.0-0: GTK+ 2 is not GNOME and should not depend on GNOME icons

[Pierre Ynard]

Hello Laurent, thanks for your explanations!

> I moved the icon theme from a Recommends to a hard Depends because
> at the same time I started removing that dependency from individual
> packages. Adding the icon theme to the individual packages was
> conceptually wrong and error-prone as there is no way to detect if an
> application needs a XDG icon theme to be installed.

I don't understand how that is conceptually wrong. It's granular and
dependent on each particular package what it needs for icons, so to me
it seems conceptually the right level for that. However I hear that you
find it error-prone and impractical to determine.

> Moving that dependency to a central place (libgtk is the library
> loading the image/icon in the end) looked like the thing to do.

I can agree with this practical approach, but GTK2.0 is not the central
place for icons or GNOME themes. It's like having firefox depend on
flash player, because you don't know if the user will browse flash
websites and firefox is the central place where browser plugins are
loaded. It's like having specific programming language modules as a
dependency of the core language support, because particular applications
written in that language don't manage their module dependencies
properly.

If anything this approach doesn't make a difference and suggests
that GNOME support is a normal part of GTK2.0's core business;
but it's really not. I would support putting the dependency on a
desktop-environment-related package or metapackage instead.

> And in a lot of cases, not having these icons might IMVHO result in a
> degraded user experience.

Reading the policy again, my understanding is that the relationship
suited to a "degraded user experience" is an uninstalled Recommends.
A "degraded user experience" implies it still works and provides a
"significant amount of functionality" without it; so a Depends is not
suitable.

On my system:

% dpkg -l | grep -i icon
ii libtext-iconv-perl 1.7-5+b3 amd64 converts between character sets in Perl

That's all. I still run firefox, pidgin, geeqie, xscreensaver and more,
just fine, without any icon theme. I don't even notice any degraded user
experience because of the lack of it. I can hardly make it clearer that
from a policy point of view, Depends is a violation; but let me know if
there's something more I can explain about this.

> One of the option would be to add a "Provides: xdg-icon-theme" (or
> something like that) virtual package to all XDG icon themes and then
> add an alternative dependency so the user could choose the icon them
> that it want to be installed. But this requires cooperation of all the
> maintainers of all the icon themes.

Okay. As a simpler version of that, does this mean that you could add
hicolor-icon-theme as a last alternative after gnome-icon-theme and
adwaita-icon-theme?

> Regarding hicolor-icon-theme package, this is the fall back icon theme
> and it's only providing a directory structure and an index.theme file.
> The total size of the installed package is neglectable.
> 
> Even if we downgrade gnome-icon-theme (and the alternatives) back to a
> Recommends (I'm not a big fan of this but others might be convinced),

I'm sorry, but in the first place, how many people have to be convinced
to refrain from a policy violation?

> hicolor-icon-theme must stay a hard dependency IMHO.

Okay, I could live with that, but - the point is still there, why must
there be a hard dependency, when GTK2.0 obviously runs fine here without
it?

Either way, I hope that we can move this forward.

Regards,

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."