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."
