Bug 183131

Sound like a broken package installation. It's not reproducible here.

Gilles Caulier

All these icons are shipped with digikam and installed by default. This must be a downstream problem. The icons you describe are "action/exifinfo", "action/imagecomment", "action/editimage", "action/colormanagement".
Did you compile manually from SVN?

This is definitely a downstream error and nothing we can help.
You can try to re-run kbuildsycoca4, maybe this helps.
I'll close this one now.

Valery,

please report the bug to your distributor, http://bugs.gentoo.org/ should be the right place.

Andi

(In reply to comment #3)
> This is definitely a downstream error and nothing we can help.
> You can try to re-run kbuildsycoca4, maybe this helps.
> I'll close this one now.
> 
> Valery,
> 
> please report the bug to your distributor, http://bugs.gentoo.org/ should be
> the right place.
> 
> Andi
> 

Ok guys we use this sed:
    # Fix files collision, use icon from kdebase-data rather that digikam ones
    sed -i \
        -e "s:add_subdirectory:#add_subdirectory:g" \
        data/icons/CMakeLists.txt || die "Failed to remove icon install"
because of you shiping the icons which are already shipped with kde, so you give us file collisions...
the colliding files are:
 * kde-base/kdebase-data-4.2.0
 *      /usr/share/icons/oxygen/128x128/apps/digikam.png
 *      /usr/share/icons/oxygen/16x16/actions/transform-crop-and-resize.png
 *      /usr/share/icons/oxygen/16x16/actions/view-object-histogram-linear.png
 *      /usr/share/icons/oxygen/16x16/actions/view-object-histogram-logarithmic.png
 *      /usr/share/icons/oxygen/16x16/apps/digikam.png
 *      /usr/share/icons/oxygen/22x22/actions/transform-crop-and-resize.png
 *      /usr/share/icons/oxygen/22x22/actions/view-object-histogram-linear.png
 *      /usr/share/icons/oxygen/22x22/actions/view-object-histogram-logarithmic.png
 *      /usr/share/icons/oxygen/22x22/apps/digikam.png
 *      /usr/share/icons/oxygen/32x32/actions/transform-crop-and-resize.png
 *      /usr/share/icons/oxygen/32x32/actions/view-object-histogram-linear.png
 *      /usr/share/icons/oxygen/32x32/actions/view-object-histogram-logarithmic.png
 *      /usr/share/icons/oxygen/32x32/apps/digikam.png
 *      /usr/share/icons/oxygen/48x48/actions/transform-crop-and-resize.png
 *      /usr/share/icons/oxygen/48x48/apps/digikam.png
 *      /usr/share/icons/oxygen/64x64/apps/digikam.png
 *      /usr/share/icons/oxygen/scalable/actions/transform-crop-and-resize.svgz
 *      /usr/share/icons/oxygen/scalable/actions/view-object-histogram-linear.svgz
 *      /usr/share/icons/oxygen/scalable/actions/view-object-histogram-logarithmic.svgz
 *      /usr/share/icons/oxygen/scalable/apps/digikam.svgz

i know that those files are probably yours so make your mind and tell kde to stop shipping them or you rely on kde and dont ship your ones.

Or at least tell me if i should really really use yours or the kde-base one

I love all those bugs resolved as 'DOWNSTREAM'... (a'ka WONTFIX)
Situation is clear:
- kdebase-runtime ships some icons
- digikam ships some icons that overwrite those from KDE
- upstream needs to decide whether to ship them here or there

If they are both here and there I dont see the reason why users get none. I'm not familiar if we pushed them to kdebase, if it's usual that KDE takes common icons. Maybe they are needed for certain KDE versions or not for others.

Users get some of them (not none) as we usually disable installing package Oxygen icons when we detect (upon source package/scripts preparation) that they are already provided by KDE. Of course we could check those icons one by one for every package but I believe upstream has more means to sort such issues out - besides statistically such issues are very rare - usually with koffice and some extragear/playground stuff - and usually after some time things are clarified and duplicates are being removed without our "intervention". Of course those packages are allowed to provide even full Oxygen icon set if they want...