Bug#682365: dpkg: native package in rc state prevents installation of m-a:foreign counterpart
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
Reply to: