By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.

Bug 2245

Summary: conflict tdelibs-data-trinity × kdebase-kio-plugins-trinity during dist-upgrade
Product: TDE Reporter: Slávek Banko <slavek.banko>
Component: tdelibsAssignee: Timothy Pearson <kb9vqf>
Status: RESOLVED FIXED    
Severity: critical CC: bugwatch, mgb-trinity, michele.calgaro, slavek.banko
Priority: P5    
Version: R14.0.0 [Trinity]   
Hardware: Other   
OS: Linux   
Compiler Version: TDE Version String:
Application Version: Application Name:
Bug Depends on:    
Bug Blocks: 2246    

Description Slávek Banko 2014-12-08 22:23:35 CST
Unpacking tdelibs-data-trinity (from .../tdelibs-data-trinity_4%3a14.0.0-r1221-0debian7.0.0+pr137_all.deb) ...
dpkg: error processing /var/cache/apt/archives/tdelibs-data-trinity_4%3a14.0.0-r1221-0debian7.0.0+pr137_all.deb (--unpack):
 trying to overwrite '/opt/trinity/share/icons/crystalsvg/48x48/devices/cdrom_unmount_encrypt.png', which is also in package kdebase-kio-plugins-trinity 4:3.5.13.2-0debian7.0.0+0
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)


This is very strange because:

Package: tdelibs-data-trinity
Section: libs
Architecture: all
Replaces: kdelibs-data-trinity (<< 4:14.0.0~)
Breaks: kdelibs-data-trinity (<< 4:14.0.0~)
Conflicts: kdebase-kio-plugins-trinity (<= 4:3.5.13.2)
Depends: hicolor-icon-theme
Provides: tdelibs-data


Dependence 'Conflicts' should ensure that the first will be updated package kdebase-kio-plugins-trinity, but obviously that did not happen. I fear that this may be the order of dependencies that can not be easily solved in apt-get. I still have to investigate and try variance apt-get dist-upgrade and aptitude dist-upgrade.
Comment 1 Slávek Banko 2014-12-09 11:53:33 CST
On my test machine I use aufs, which allows me to repeatedly try progress of upgrade from R3.5.13.2 to R14.0.0.

For all experiments were identical:
1) Modify the apt sources.
2) Perform apt-get update.

Then I compared the upgrade using apt-get dist-upgrade versus aptitude dist-upgrade.

3a) Where I used apt-get dist-upgrade, I repeatedly ran into problems described in the comment 0. In my case, then not helped apt-get install -f. It was necessary for manual intervention using dpkg.

3b) Where I used aptitude dist-upgrade, update had always totally smooth process.

It seems that the apt-get will not solve the optimal order of packages for the update. In addition, when using the apt-get (unless I explicitly did not specify --no-install-recommends) was strangely installed packages such as gdm and gnome-keyring.

It shows me a clear conclusion: for update from TDE 3.5.x to TDE R14.x is advisable to use solely aptitude.
Comment 2 Michele Calgaro 2014-12-09 21:10:34 CST
> It shows me a clear conclusion: for update from TDE 3.5.x to TDE R14.x is 
> advisable to use solely aptitude.
aptitude is definitely a *very* good tool. I basically never use apt-get for upgrades, just aptitute and occasionally dpkg directly.

Having said that, I wonder if the problem is caused by the fact that the conflict line is:

Conflicts: kdebase-kio-plugins-trinity (<= 4:3.5.13.2)

but the package version is 

kdebase-kio-plugins-trinity 4:3.5.13.2-0debian7.0.0+0.

I don't know what apt-get does to resolve dependency order, but have you tried with a conflict line as the following one?

Conflicts: kdebase-kio-plugins-trinity (<< 4:14.0.0~)

Reason for asking is that 4:3.5.13.2 is in Debian package order strictly less than 4:3.5.13.2-0debian7.0.0+0, so maybe this confises apt-get.
Comment 3 mgb-trinity 2014-12-10 04:42:24 CST
I confirm that an "apt-get dist-upgrade" from a clean 3.5.13.2 install to R14 RC2 fails for the reason given by Michele.
Comment 4 Michele Calgaro 2014-12-26 07:27:12 CST
Slavek, didn't you just fix this in yesterday commit?
Comment 5 Slávek Banko 2014-12-26 07:41:33 CST
(In reply to Michele Calgaro from comment #4)
> Slavek, didn't you just fix this in yesterday commit?

Yes, exactly. Yesterday commit should solve this problem. The bug report I left open for now, until I will rebuild packages and checking whether the problem is really resolved.

Thank you for assignment this to bug 2246.
Comment 6 Slávek Banko 2014-12-27 18:41:17 CST
Fixed in GIT hash d528497c (master) and 19215f82 (r14.0.x)