On Sun, Jul 22, 2012 at 05:13:00AM +0200, Guillem Jover wrote: > 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.
That doesn't track. That would require all conffiles to be split off into architecture:all packages for no good reason. The packages is M-A: foreign. That imho means it will have to work with its conffiles from any architecture, i.e. the conffiles need to be architecture independent. As M-A:foreign package libwine:i386 is a full replacement for libwine:amd64 in every way and that should include conffiles in dpkg. Otherwise cross-grading will be a total nightmare. > > 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 Are you sayind that configuration files must be purged when cross-grading packages? That looks like a serious implementation flaw in dpkg. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org