Proposal for update to packaging guidelines for icon files

[Kevin Kofler]

Richard Shaw wrote:
> 1. If installing icons into in to /usr/share/pixmaps is indeed
> deprecated.

It's not installing into /usr/share/pixmaps which is deprecated, but the 
whole concept of unthemed, fixed-size icons.

> Then we need to update the packaging guidelines for the Desktop Files
> section[2]. In the "Icon tag in Desktop Files" section it explicitly shows
> a full path to an icon file in /usr/share/pixmaps.

Because that's the standard path for unthemed, fixed-size icons.

> While not intended as a guideline, it should be revised to showing a
> full path to an icon in /usr/share/icons/hicolor

No. It makes no sense whatsoever to reference /usr/share/icons/hicolor with 
an absolute path!

The guideline should instead be changed to make it clear that using an 
absolute path there is deprecated and the other method should be preferred.

> (probably in the 48x48 directory since it's the minimum requirement[3].)

That is just a suggestion, not a requirement. For example, KDE Plasma 
doesn't actually use 48×48 anywhere, it uses 32×32 in Kickoff and 16×16 in 
the classic menu, so if you're designing for Plasma, having only a 48×48 
icon is suboptimal.

> 2. It may even be better to create a separate section for icons.
> Because the guidelines require us to "Requires:" a package when we
> install a file into a directory that the package does not own,
> theoretically all packages that install icons into
> /usr/share/icons/hicolor need to "Requires: hicolor-icon-theme". This
> should probably be explained more directly.

Not just theoretically, but pratically. This is a MUST requirement.

The whole purpose of hicolor-icon-theme is to be required by any package 
which installs any icons. It contains no actual icons, but just an empty 
theme for applications to install their icons into. Any application 
installing icons to hicolor MUST Require hicolor-icon-theme. Packages not 
doing that must be fixed.

        Kevin Kofler