On 03/30/2012 02:14 PM, Darrell Anderson wrote: 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.

I don't have a problem with removing cruft. Usually a Good Thing. Just every time we see these things the bug tracker grows and I feel us all sinking deeper. As you noted, where do we find the time? :) After searching the entire source tree, I concluded those vimrc and config.log files are from somebody on the Trinity team.... :) My clues are the vimrc files are exactly the same (same person) and the config.log files all include references to /opt/trinity. I don't use vim and I'm paranoid about working directly within the source tree (I always make copies). I counted 16 config.log files and three vimrc files. Not many. I'll purge them. Darrell --------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting

On 30 March 2012 15:50, Darrell Anderson <humanreadable(a)yahoo.com> wrote: you can check when they were commited and by who using some git foo :-P

--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting

After searching the entire source tree, I concluded those vimrc and config.log files are from somebody on the Trinity team.... :) My clues are the vimrc files are exactly the same (same person) and the config.log files all include references to /opt/trinity. I don't use vim and I'm paranoid about working directly within the source tree (I always make copies). I counted 16 config.log files and three vimrc files. Not many. I'll purge them.

I did it in tdeaccessibility packaging: package() { msg "Packaging - $pkgname-$pkgver" cd ${srcdir}/${pkgname#*-} # use for non-out-of-source make DESTDIR="$pkgdir" install # remove icons that conflict with tdelibs msg "Removing kttsd.png icons that conflict with tdelibs..."

On 30 March 2012 16:51, Darrell Anderson <humanreadable(a)yahoo.com> wrote: They appear to be duplicates 2:-rw-r--r-- 1 calvin calvin 23932 2011-10-02 13:05 cr128-app-kttsd.png 3:-rw-r--r-- 1 calvin calvin   965 2011-10-02 13:05 cr16-app-kttsd.png 4:-rw-r--r-- 1 calvin calvin  1509 2011-10-02 13:05 cr22-app-kttsd.png 5:-rw-r--r-- 1 calvin calvin  2688 2011-10-02 13:05 cr32-app-kttsd.png 6:-rw-r--r-- 1 calvin calvin  5039 2011-10-02 13:05 cr48-app-kttsd.png 7:-rw-r--r-- 1 calvin calvin  7877 2011-10-02 13:05 cr64-app-kttsd.png 8:-rw-r--r-- 1 calvin calvin 17596 2011-10-02 13:05 crsc-app-kttsd.svgz calvin@boxi:~/builds/kde.org/trinity/kdelibs/pics/crystalsvg$ ls -l | grep kttsd 7:-rw-r--r-- 1 calvin calvin 23932 2011-10-02 13:16 cr128-app-kttsd.png 397:-rw-r--r-- 1 calvin calvin   965 2011-10-02 13:16 cr16-app-kttsd.png 807:-rw-r--r-- 1 calvin calvin  1509 2011-10-02 13:16 cr22-app-kttsd.png 1136:-rw-r--r-- 1 calvin calvin  2688 2011-10-02 13:16 cr32-app-kttsd.png 1359:-rw-r--r-- 1 calvin calvin  5039 2011-10-02 13:16 cr48-app-kttsd.png 1550:-rw-r--r-- 1 calvin calvin  7877 2011-10-02 13:16 cr64-app-kttsd.png 1791:-rw-r--r-- 1 calvin calvin 17596 2011-10-02 13:16 crsc-app-kttsd.svgz calvin@boxi:~/builds/kde.org/trinity/kdelibs/pics/crystalsvg$ Calvin

They appear to be duplicates

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

I agree and I cuss pacman every once in a while for it. It is more restrictive and it does a very good job. I just wish it was smart enough to: if diff pkg1/file.x pkg2/file.x; then install the darn thing fi But.. then you screw up (or complicate) the package manager database regarding who owns what on the system. I think this is where other package managers are smarter than pacman. Their package databases seem to be able to do this on the fly while pacman doesn't. Because in the above example, you would need to expand it to: if diff pkg1/file.x pkg2/file.x; then install the darn thing update_pkgmgr_db(pkg2/file.x, owned by pkg2) update_pkgmgr_db(pkg1/file.x, owned by pkg2) fi