[Bug 1080411] Review Request: trojita - Qt IMAP e-mail client

bugzilla at redhat.com bugzilla at redhat.com
Mon Nov 3 16:47:59 UTC 2014


https://bugzilla.redhat.com/show_bug.cgi?id=1080411



--- Comment #18 from Karel Volný <kvolny at redhat.com> ---
(In reply to Kevin Kofler from comment #17)
> The icon-theme.cache file is actually ghosted, which means it is NOT part of
> the installed size of the hicolor-icon-theme package.

okay, sorry, I've used improper logical shortcut no file installed = no space
eaten

> And gtk-update-icon-cache will create that file whether you have the
> hicolor-icon-theme package installed or not.

well, in that case, wouldn't that be better if the file is owned by gtk2, which
provides gtk-update-icon-cache?

> -rw-r--r--   1 root root     27095 27. Feb 2014  /usr/share/icons/hicolor/index.theme
> required by the freedesktop.org icon theme spec. Strictly speaking, installing
> an icon to hicolor without that file being present is meaningless.

strictly speaking yes, but in case you're not interested in icons, it's still a
little bit better to just install the unwanted icon (when it is not in separate
package) rather than to install icon+theme

> The total installed size of hicolor-icon-theme is a whopping 48208 bytes. I
> would understand your complaint if we were still shipping the original
> hicolor-icon-theme from KDE 2, which contained actual icons (that's where
> the "hicolor" name historically comes from), but as it stands, you are just
> splitting hairs (or not understanding the meaning of %ghost in RPM).

I don't think the approach "it's just X bytes, next to nothing, let's waste it"
is the best ...

but that would be a different point

I'm not quite sure about the interpretation of the packaging guidelines ... if
you say depending on hicolor-icon-theme is the best thing to do (and I don't
say it isn't, just that in my POV it's not that clear), please file a request
to change the guidelines to mandate hicolor-icon-theme dependency for packages
installing icons, and once it gets changed, we are over with this discussion -
and as a bonus, bugs for other packages owning those directories could be filed
then so that the mess gets cleaned up

wouldn't it be better to make it absolutely clear for all the packagers rather
than arguing here?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component


More information about the package-review mailing list