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?

I agree with David.

I don't see how anyone would use one without tdelibs, so you might as well remove the files from accessibility.

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? :)

I consider this part of the cruft, along with old vimrc files :-)

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

you can check when they were commited and by who using some git foo :-P

Nuh-uh --- YOU can check.... :)

Darrell

On 03/30/2012 02:51 PM, Calvin Morrison wrote:

you can check when they were commited and by who using some git foo :-P

Often valor is the better use of discretion -- sometimes protecting the name of the guilty is required :)

On 03/30/2012 02:39 PM, Calvin Morrison wrote:

I agree with David.

I don't see how anyone would use one without tdelibs, so you might as well remove the files from accessibility. I consider this part of the cruft, along with old vimrc files :-)

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..." rm ${pkgdir}/opt/trinity/share/icons/crystalsvg/16x16/apps/kttsd.png rm ${pkgdir}/opt/trinity/share/icons/crystalsvg/22x22/apps/kttsd.png rm ${pkgdir}/opt/trinity/share/icons/crystalsvg/32x32/apps/kttsd.png rm ${pkgdir}/opt/trinity/share/icons/crystalsvg/48x48/apps/kttsd.png rm ${pkgdir}/opt/trinity/share/icons/crystalsvg/64x64/apps/kttsd.png rm ${pkgdir}/opt/trinity/share/icons/crystalsvg/128x128/apps/kttsd.png rm ${pkgdir}/opt/trinity/share/icons/crystalsvg/scalable/apps/kttsd.svgz }

On 30 March 2012 16:51, Darrell Anderson humanreadable@yahoo.com wrote:

...

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..."

Silly question of the day, but are the files exactly the same? I mean did you look at them? :)

Darrell

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

On 30 March 2012 16:59, Calvin Morrison mutantturkey@gmail.com wrote:

On 30 March 2012 16:58, Calvin Morrison mutantturkey@gmail.com wrote:

...

On 30 March 2012 16:51, Darrell Anderson humanreadable@yahoo.com wrote:

...

...

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..."

Silly question of the day, but are the files exactly the same? I mean did you look at them? :)

Darrell

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

Even though I accidentally just was in the old KDE.org svn heh :-) they still are duplicates in git!

Calvin

Just found this: tde/main/tdeaccessibility/kttsd/compat/README_COMPAT

This is a directory to keep compatibility in KTTSD. This directory permits distribution and compilation of the following kttsd components: If KDE < 3.4, copy of tdelibs/interfaces/kspeech. If KDE < 3.5, copy of tdelibs/pics (kttsd icons only)

Last Sync: Sat Mar 26 18:00:00 EST 2004 by Gary Cramblitt (PhantomsDad) garycramblitt@comcast.net

I wonder why!

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

On 30 March 2012 16:16, David C. Rankin drankinatty@suddenlinkmail.com wrote:

On 03/30/2012 02:40 PM, Darrell Anderson wrote:

...

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

Honestly i've dealt with the pacman maintainers and contributors. Nothing they do is unintentional :-). If packages are conflicting, the best way to tell them not to is to just force them not to.

Situation: when package A and B conflict over X.txt

what happens when I uninstall B, do we remove X.txt? obviously you shouldn't do that, especially because A needs it too. So what if A has a new version? we over write it?

I just think the best way it to tell packages to sort their own crap out, that way you don't go down a long dark hole of overly complicated problems and errors that could take forever to track down because a file isn't where it needs to be.

I like pacman because it is restrictive :-)

Anyway, the solution isn't to fix pacman, it's to fix trinity.

Calvin

On 03/30/2012 03:59 PM, Darrell Anderson wrote:

Oh, boy. I could say something now in defense for why the Slackware packaging system never required dependency checking.... :)

There is no database, no Central Headquarters. Just tgz packages....

Slackware installs the dam*ed thing and expects the user to know better. Yeah, not all users pay attention, but the package tools do pay attention to what gets removed. When two packages have installed the same file the package tools do not argue and leaves the files untouched during the removal process.

Oh never mind. I'll start a distro war soon!

Darrell

Nah,

I see likes and dislikes in all the distros I've run. rpm based, pacman based, deb based, tgz based - all are fine.

good distro = good out of the box package selection + good list with good people

The rest is just noise...