[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#277890: xutils: file conflict with xbase-clients 4.3.0.dfsg.1-8



reassign 277890 dpkg
tag 277890 - wontfix
retitle 277890 dpkg: better handle upgrades between versions of packages affected by Replaces:
thanks

(Explanation follows.)

On Tue, Oct 26, 2004 at 02:46:07PM -0400, Andrew Pimlott wrote:
> On Mon, Oct 25, 2004 at 01:46:30PM -0500, Branden Robinson wrote:
> > 
> > On Sat, Oct 23, 2004 at 02:44:05AM -0400, Andrew Pimlott wrote:
> > > Package: xutils
> > > Version: 4.1.0-16woody3
> > > Severity: minor
> > > 
> > > When upgrading xutils on my mixed stable/unstable system, I got
> > > 
> > >     Preparing to replace xutils 4.1.0-16woody3 (using .../xutils_4.1.0-16woody4_i386.deb) ...
> > >     Unpacking replacement xutils ...
> > >     dpkg: error processing /var/cache/apt/archives/xutils_4.1.0-16woody4_i386.deb (--unpack):
> > >      trying to overwrite `/usr/X11R6/bin/atobm', which is also in package xbase-clients
> > > 
> > > This is evidently because I have xbase-clients 4.3.0.dfsg.1-8 installed.
> > > 
> > > No worries if you don't want to support this configuration.
> > 
> > This is not something I think I *can* fix.
> > 
> > I don't think xutils Replaces: xbase-clients (<= 4.3.0.dfsg.1-7) is
> > something that makes sense to add to woody, nor do I think Martin Schulze
> > would accept such a change.
> > 
> > If there is a fix for this, it lies in dpkg.  Every time even one package
> > is upgraded, dpkg would have to rescan the Replaces: headers of all
> > already-installed packages to see if this error would be suppressed by one
> > of them.  It could do this on a per-run basis, I suppose, so it would only
> > be inefficient if you used dpkg a lot to upgrade only one package at a time.
> 
> Ok, I see that my current xbase-clients has
> 
>     Replaces: xutils (<< 4.3.0.dfsg.1-7)
> 
> I had assumed that this (or something similar) was missing
> xbase-clients, so that there would be a simple resolution.  I now
> understand why this isn't sufficient (though it was entirely non-obvious
> to me).  The implicit assumption is that a Replaced package will not be
> upgraded to one that still contains the overwritten file.  Interesting.
> 
> I agree that you don't have any palatable option.  However, I think dpkg
> could handle this without any performance hit.  All it has to do is,
> after detecting an attempted overwrite, see whether the existing owner
> of the file Replaces the package being installed.  (This won't handle a
> change of two Replaces, but ...)
> 
> (Obviously, I should have filed the bug on xbase-clients if I had really
> thought this through.)
> 
> Andrew
> 
> [1] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

Okay.  I am reassigning this bug to dpkg.

-- 
G. Branden Robinson                |       If you want your name spelled
Debian GNU/Linux                   |       wrong, die.
branden@debian.org                 |       -- Al Blanchard
http://people.debian.org/~branden/ |

Attachment: signature.asc
Description: Digital signature


Reply to: