Darrell,
We have run into another icon conflict error. I know some package managers do not care and will let you overwrite icons, fonts, etc.., but Arch's pacman package manager will not let you overwrite anything in the filesystem on the theory that "No package should conflict with another". Of course you can --force any install and removal, but that defeats the purpose of proper packaging.
There are a couple of TDE icons that are present in several different packages. If one package is installed before any other containing the same icons, then install of the subsequent packages fails. At issue are:
tde-tdeaddons-14.0.0-1-i686.pkg.tar.xz
opt/trinity/share/icons/locolor/32x32/apps/ktimemon.png opt/trinity/share/icons/locolor/16x16/apps/ktimemon.png
tde-tdeartwork-14.0.0-1-i686.pkg.tar.xz
opt/trinity/share/icons/locolor/32x32/apps/ktimemon.png opt/trinity/share/icons/locolor/32x32/apps/kbabel.png opt/trinity/share/icons/locolor/16x16/apps/ktimemon.png opt/trinity/share/icons/locolor/16x16/apps/kbabel.png
tde-tdesdk-14.0.0-1-i686.pkg.tar.xz
opt/trinity/share/icons/locolor/32x32/apps/kbabel.png opt/trinity/share/icons/locolor/16x16/apps/kbabel.png
So this has to be handled from a packaging standpoint on arch. Fortunately, the package that contains all icons at issue is tdeartwork. For Arch, I will write conditional checks for tdeaddons and tdesdk to avoid the issue.
How are the other distros handling this? Can TDE move these conflicting icons to tdeartwork exclusively.
On Wednesday 29 of January 2014 00:20:12 David C. Rankin wrote:
Darrell,
We have run into another icon conflict error. I know some package managers do not care and will let you overwrite icons, fonts, etc.., but Arch's pacman package manager will not let you overwrite anything in the filesystem on the theory that "No package should conflict with another". Of course you can --force any install and removal, but that defeats the purpose of proper packaging.
There are a couple of TDE icons that are present in several different packages. If one package is installed before any other containing the same icons, then install of the subsequent packages fails. At issue are:
tde-tdeaddons-14.0.0-1-i686.pkg.tar.xz
opt/trinity/share/icons/locolor/32x32/apps/ktimemon.png opt/trinity/share/icons/locolor/16x16/apps/ktimemon.png
tde-tdeartwork-14.0.0-1-i686.pkg.tar.xz
opt/trinity/share/icons/locolor/32x32/apps/ktimemon.png opt/trinity/share/icons/locolor/32x32/apps/kbabel.png opt/trinity/share/icons/locolor/16x16/apps/ktimemon.png opt/trinity/share/icons/locolor/16x16/apps/kbabel.png
tde-tdesdk-14.0.0-1-i686.pkg.tar.xz
opt/trinity/share/icons/locolor/32x32/apps/kbabel.png opt/trinity/share/icons/locolor/16x16/apps/kbabel.png
So this has to be handled from a packaging standpoint on arch. Fortunately, the package that contains all icons at issue is tdeartwork. For Arch, I will write conditional checks for tdeaddons and tdesdk to avoid the issue.
How are the other distros handling this? Can TDE move these conflicting icons to tdeartwork exclusively.
You hit on an issue that has been reported as an bug 1282. For Debian and Ubuntu conflict was resolved in packaging. However, the crux of the problem was not solved. At the time, the problem was also discussed here on the mailing-list - see thread A few duplicate locolor icons.
http://bugs.trinitydesktop.org/show_bug.cgi?id=1282 http://trinity-devel.pearsoncomputing.net/?0::10366
Slavek --
On Tue, 28 Jan 2014 17:20:12 -0600 "David C. Rankin" drankinatty@suddenlinkmail.com wrote:
How are the other distros handling this? Can TDE move these conflicting icons to tdeartwork exclusively.
Well, that's . . . interesting. The problem of the dual icons existed in stock KDE3, and Gentoo seems to have avoided the file collision by an insane technicality: kbabel installs to share/icons/locolor/ and kdeartwork installs to share/icons/Locolor/ . There's no explanatory note anywhere, so I have to assume that that happened by accident, and the quirk may have been present in other distros as well.
Do we have a policy on what to do with non-core applications that ship icons for the core icon sets? It probably doesn't matter whether we send these to kdeartwork or their respective packages, but it would be nice to be consistent about where the files end up.
E. Liddell