trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: March 2012

Re: [trinity-devel] tdeaccessibility crystalsvg icons conflict with tdelibs

From: Darrell Anderson <humanreadable@...>
Date: Fri, 30 Mar 2012 12:40:00 -0700 (PDT)
>   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?

Okay, but I'm confused as to why nobody in the history of KDE3 complained about the problem. That's why I asked whether there was a problem. :)

In Slackware I never noticed a problem. The package manager will not remove files when another package installed the same files (overlap). I don't see a problem with overwriting during installation, but I see a problem with blindly removing files when two packages install the same files.

Installing the same files from two different packages might seem inefficient, but does not break anything. The breakage occurs when the package manager removes files blindly. Seems like the Arch package manager default settings are more restrictive than other package managers by not letting the installation proceed without using the --force parameter. :) Not bad or good, just more restrictive. To me, the removal end is more important.

Darrell