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?

-- 
David C. Rankin, J.D.,P.E.