Ubuntu
dpkg package

wishlist: handling of duplicate files

Bug #228429 reported by Paul Bransford
2
Affects Status Importance Assigned to Milestone
dpkg (Ubuntu)
Confirmed
Wishlist
Unassigned

Bug Description

Binary package hint: dpkg

I just ran into a package bug where two packages handled the same file, and this prevented the installation of the second package without passing "--force-overwrite". The file in question was exactly the same between both packages.

It would be nice if there was an intelligent way of handling this situation when both files have the same MD5 hash, as in that case it doesn't matter which package's version goes in, as long as the file persists for the life of BOTH packages. Granted, this is still a bug in the package, not the package manager, but some way of handling this besides mucking with dpkg directly or waiting for an update would be neat (or, prompt for overwrite rather than erroring out?

Caroline Ford (secretlondon)
Changed in dpkg:
importance: Undecided → Wishlist
Revision history for this message
Richard Seguin (sectech) wrote :

Thank you for this report,

Would you be willing to create a bug report stating which packages are conflicting? It's a fairly uncommon bug so it's helpful to catch the conflicting packages whenever we can...

Thanks in advance,

Richard

Revision history for this message
Paul Bransford (draeath) wrote : Re: [Bug 228429] Re: wishlist: handling of duplicate files

Already got one open (well, someone else did, I just added that I had
it too on a different arch, and noted the files were the same)

(libqt4-dev and libqt4-opengl-dev, i think versions 4.4.0)

On Thu, May 8, 2008 at 9:11 PM, Richard Seguin
<email address hidden> wrote:
> Thank you for this report,
>
> Would you be willing to create a bug report stating which packages are
> conflicting? It's a fairly uncommon bug so it's helpful to catch the
> conflicting packages whenever we can...
>
> Thanks in advance,
>
> Richard
>
> --
> wishlist: handling of duplicate files
> https://bugs.launchpad.net/bugs/228429
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Paul Bransford (draeath) wrote :

Found it, Bug #228148 in qt4-x11 (Ubuntu)

Richard Seguin (sectech)
Changed in dpkg:
status: New → Confirmed
Revision history for this message
RK (kubuntu-rk) wrote :

> Would you be willing to create a bug report stating which packages are conflicting? It's a fairly uncommon bug ...

LOL.

As a matter of fact, conflicting files happen quite frequently during dist upgrades, in particular since preceding year's KDE packages' quality essentially required the use of PPAs.

Anyway, if conflicting files happen, dpkg should add the package to a list of conflict packages, if the package(s) it conflicts with is(are) also to be updated, and retry them later. Or, in a simpler way, put the package to a list of conflict packages, then if any package has been successfully installed, restart unpacking with this list of packages. This would solve most of the conflicts happening during dist upgrade, because conflicts within the dist are indeed uncommon.

Also impending the stableness of dpkg is the fact that any kind of upgrade through dselect can result in a broken state that cannot be resolved within dselect, sometimes not even within apt-get. Example: upgrading amarok1 to amarok2 from karmic, required some libqtscript4-* packages, which failed due to conflicts to libqtscriptbindings1=0.1.0-0ubuntu1~jaunty1. With libqtscript4-* failed, broken dependancies do not allow to remove libqtscriptbindings1; directly calling dpkg -r and then apt-get install -f is necessary to remedy the situation. Maybe dpkg should automatically store a conflicts between packages when they end up trying to overwrite each other's files. Then at least an apt-get install -f would pick up those and know to remove libqtscriptbindings1 by itself.

If then apt-get automatically does a -f, then a lot of robustness has been achieved that is currently missing.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.