On 03/30/2012 02:14 PM, Darrell Anderson wrote:
Does your build environment make these checks?
I have been building KDE3 and TDE for a long time. Even if there are some file overwrites, I never have noticed any problems. Is there a problem?
Darrell
Yes,
There is a problem! Both packages provide:
/opt/trinity/share/icons/crystalsvg/16x16/apps/kttsd.png /opt/trinity/share/icons/crystalsvg/22x22/apps/kttsd.png /opt/trinity/share/icons/crystalsvg/32x32/apps/kttsd.png /opt/trinity/share/icons/crystalsvg/48x48/apps/kttsd.png /opt/trinity/share/icons/crystalsvg/64x64/apps/kttsd.png /opt/trinity/share/icons/crystalsvg/128x128/apps/kttsd.png /opt/trinity/share/icons/crystalsvg/scalable/apps/kttsd.svgz
You can't have 2 packages provide the same files and not have a conflict. To an extent, it depends on your package manager. In arch, the package manager 'pacman' checks for file conflicts in the system before installing packages and blindly overwriting files. Since tdelibs provides the kttsd.png icons, when tdeaddessibility install attempt is made, it fails do to conflicting files.
Yes, I could --force the install and simply overwrite the kttsd.png icons, but that is a sloppy way of doing it. Here, the options would be to:
(1) have either tdelibs or tdeaccessibility provide the files - from a packaging standpoint - it makes sense to have them installed in tdelibs, because you ain't runnin without it :); or
(2) probably the 'proper' way to do it from a TDE standpoint is to split all of the icons out into packages like:
tde-icons-crystal tde-icons-hicolor etc...
and make those dependencies of tdelibs. That way the icon sets could contain every conceivable icon in the world and not conflict with any subsequent package.
At this point in R14 development -- it's a packaging issue, but to clean things up why have multiple copies of icons existing in the tree?