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

Re: Bug#682365: dpkg: native package in rc state prevents installation of m-a:foreign counterpart



reassign 682365 apt
thanks

On Sun, 2012-07-22 at 04:37:02 +0200, Arno Schuring wrote:
> Package: dpkg
> Version: 1.16.4.3
> Severity: normal

> It appears that dpkg's logic to prevent installing different versions
> of a multi-arch:foreign package considers removed but-not-purged
> packages as still installed:
> 
> dpkg: error processing /var/cache/apt/archives/libwine_1.4.1-2_i386.deb
> (--unpack): libwine:i386 1.4.1-2 (Multi-Arch: foreign) is not
> co-installable with libwine which has multiple installed instances
> 
> rc  libwine:amd64   1.4.1-1.2    Windows API implementation - library
> ii  libwine:i386    1.4.1-1.2    Windows API implementation - library
> 
> 
> This leads to the odd situation that migrating from one architecture to
> another in effect requires you to purge the package (and lose config,
> although I'm not sure m-a:foreign packages can even support config
> files).

Yes, that's on purpose, otherwise the database could end up with
multiple instances of non-coinstallable packages, which would break
lots of internal and external assumptions. And yes, any package could
contain conffiles, in the libwine case I'd assume it's just the postrm
maintainer scripts that remains.

> The full log of what I was trying to do (shortened for brevity though):
> 
> # apt-get -t sid install libwine:i386 [..]
> [..]
> The following packages will be REMOVED:
>   libwine [..]
> The following packages will be upgraded:
>   libwine:i386 [..]
> [..]
> Removing libwine:amd64 ...
> [..]
> Preparing to replace libwine-bin:i386 1.4.1-1.2
> (using .../libwine-bin_1.4.1-2_i386.deb) ... Unpacking replacement
> libwine-bin:i386 ... dpkg: error
> processing /var/cache/apt/archives/libwine_1.4.1-2_i386.deb (--unpack):
> libwine:i386 1.4.1-2 (Multi-Arch: foreign) is not co-installable with
> libwine which has multiple installed instances [..] # dpkg -la|grep
> libwine rc  libwine:amd64
> 1.4.1-1.2                          Windows API implementation - library
> ii  libwine:i386
> 1.4.1-1.2                          Windows API implementation - library
> [..] # dpkg -P libwine:amd64 (Reading database ... 125749 files and
> directories currently installed.) Removing libwine:amd64 ...
> Purging configuration files for libwine:amd64 ...
> # apt-get -t sid install -f
> [..]
> The following extra packages will be installed:
>   libwine:i386
> [..]
> The following packages will be upgraded:
>   libwine:i386
> [..]
> Unpacking replacement libwine ...
> [..]
> Setting up libwine (1.4.1-2) ...
> # dpkg -la|grep libwine
> ii  libwine
> 1.4.1-2                            Windows API implementation - library
> ii  libwine-bin:i386
> 1.4.1-2                            Windows API implementation - system
> services [..]

> I also notice that libwine no longer is listed as libwine:i386. Not
> sure where that comes from though. Maybe because there is a
> non-multiarch libwine in stable?

libwine 1.4.1-2 is not arch-qualified because it's not Multi-Arch:same
anymore and as such does not really need to be disambiguated.

> Filing against dpkg because I think configuration-only packages should
> not prevent installation like this, but if this is expected behaviour
> then this bug might need to be reassigned to apt so that apt knows to
> purge packages in this situation. I also looked through the 1.16.8
> changelog but saw no mention of something like this already being
> fixed, and I also don't know if 1.16.8 might or might not make it into
> wheezy.

Yes, this appears to be a problem with apt, reassigning as such.

thanks,
guillem


Reply to: