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.2Windows API implementation - library ii libwine:i3861.4.1-1.2Windows 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-2Windows API implementation - library ii libwine-bin:i386 1.4.1-2Windows 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
Bug#682365: dpkg: native package in rc state prevents installation of m-a:foreign counterpart
On Sun, Jul 22, 2012 at 05:51:08AM +0200, Guillem Jover wrote: On Sat, 2012-07-21 at 22:30:30 -0500, Jonathan Nieder wrote: Guillem Jover wrote: On Sun, 2012-07-22 at 04:37:02 +0200, Arno Schuring wrote: dpkg: error processing /var/cache/apt/archives/libwine_1.4.1-2_i386.deb [...] rc libwine:amd64 1.4.1-1.2Windows API implementation - library ii libwine:i3861.4.1-1.2Windows API implementation - library [...] 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. How does crossgrading normally work? Cross-grading happens whenever a new package instance is installed with a different architecture from the current single instance, as long as both old and new are not M-A:same, or they switch from non-M-A:same to M-A:same or the reverse. If Arno had not had libwine:i386 installed, would the upgrade have worked? Yeah (assuming not-installed == not-present), that would have been a cross-grade. Because the old one is M-A:same and the new one is M-A:foreign. Corect me if I'm wrong but your saying the following work: foo:i386 same 1.2-3 - foo:i386 foreign 1.2-4 foo:amd64 same 1.2-3 - foo:i386 foreign 1.2-4 foo:i386 same 1.2-3 - foo:amd64 foreign 1.2-4 foo:amd64 same 1.2-3 - foo:amd64 foreign 1.2-4 But not: foo:amd64 same 1.2-3 -\ - foo:i386 foreign 1.2-4 foo:i386 same 1.2-3 -/ MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682365: dpkg: native package in rc state prevents installation of m-a:foreign counterpart
On Mon, 2012-07-23 at 10:52:16 +0200, Goswin von Brederlow wrote: On Sun, Jul 22, 2012 at 05:13:00AM +0200, Guillem Jover wrote: 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. As I explicitly said above (“any package could contain conffiles“), conffiles work just fine in M-A:same, they are just ref-counted as any other files, I don't see where you got that impression. Are you sayind that configuration files must be purged when cross-grading packages? That looks like a serious implementation flaw in dpkg. I don't see where I said that either, I've just said that *packages* in config-files state need to be purged whenever there's multiple instances present and one wants to switch to a non-M-A:same packages. regards, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682365: dpkg: native package in rc state prevents installation of m-a:foreign counterpart
On Mon, 2012-07-23 at 11:06:31 +0200, Goswin von Brederlow wrote: On Sun, Jul 22, 2012 at 05:51:08AM +0200, Guillem Jover wrote: On Sat, 2012-07-21 at 22:30:30 -0500, Jonathan Nieder wrote: How does crossgrading normally work? Cross-grading happens whenever a new package instance is installed with a different architecture from the current single instance, as long as both old and new are not M-A:same, or they switch from non-M-A:same to M-A:same or the reverse. If Arno had not had libwine:i386 installed, would the upgrade have worked? Yeah (assuming not-installed == not-present), that would have been a cross-grade. Because the old one is M-A:same and the new one is M-A:foreign. Corect me if I'm wrong but your saying the following work: foo:i386 same 1.2-3 - foo:i386 foreign 1.2-4 foo:amd64 same 1.2-3 - foo:i386 foreign 1.2-4 foo:i386 same 1.2-3 - foo:amd64 foreign 1.2-4 foo:amd64 same 1.2-3 - foo:amd64 foreign 1.2-4 But not: foo:amd64 same 1.2-3 -\ - foo:i386 foreign 1.2-4 foo:i386 same 1.2-3 -/ Yes (where ‘foreign’ could be also ‘allowed’ or implicit ‘no’). regards, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682365: dpkg: native package in rc state prevents installation of m-a:foreign counterpart
Hi!
On Sun, 2012-07-22 at 00:23:43 -0500, Jonathan Nieder wrote:
Guillem Jover wrote:
On Sat, 2012-07-21 at 22:30:30 -0500, Jonathan Nieder wrote:
What dpkg commands should apt run to upgrade from this state?
In this particular case, apt would need to check that there's no multiple
instances present if the new package is switching from M-A:same to
non-M-A:same. And in that case notify the user that the package instance
in config-files state would need to be purged.
Makes sense. Thanks for explaining.
No problem. :)
This idea of purging one arch of a package while keeping other arches
is still new to me.
Well that could happen still due to explicit user request, so it's
something that needs to work correctly from the maintainer script
point of view anyway, and the consequences of this are due to the
file ref-counting, which in the maintainer scripts case will need
to be handled semi-manually for files not tracked by dpkg.
+ libc6.postrm purge runs db_purge. The corresponding 'owner' is
arch-qualified, making this safe.
+ Likewise for libpam0g, libpam-modules, libssl1.0.0, etc.
That's been one of the reasons to always arch-qualify package names
for M-A:same packages, yes.
? libc6-i686.postrm remove and other optimized libc packages use
dpkg-query -l to find the version of all optimized libc packages.
The parsing does not take the colon in Multi-Arch: same packages
into account, so it never notices that all have been upgraded in
order to remove /etc/ld.so.nohwcap.
This might need to be checked, I pointed to watch for this kind of
issue in my mail to d-d-a, though.
+ libglib2.0-0.postrm purges some caches that are not
architecture-specific. This is probably harmless because they are
caches.
It's still wasteful and unneeded, should get fixed, but not too
serious.
- libgphoto2-2.postrm purges .dpkg-bak files representing user
customized obsolete configuration files without checking if another
arch is staying around to take responsibility for them.
- libgtk-2.0-0.postrm purge wipes out /etc/gtk-2.0/*
- likewise for libgtk-3-0
- liblockfile1.postrm remove wipes out its documentation directory
(!)
- libpaper1.postrm purge removes /etc/papersize and the
corresponding ucf configuration
- libuuid1.postrm purge removes /var/lib/libuuid
- libwrap0.postrm purge removes /etc/hosts.{allow,deny}
- libzvbi0.postrm purge removes /etc/default/libzvbi0
Yeah, all the above should get bugs reports.
Those are just the libraries I currently have installed on the machine
I am using to type this.
I guess a general bug is in order.
I'm not sure that will help much. Instead I guess a mail to d-d might be
bettet given that people seems to have not realized the consequences of
ref-counting files. And then individual bugs being filed.
thanks,
guillem
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682365: dpkg: native package in rc state prevents installation of m-a:foreign counterpart
Guillem Jover (guil...@debian.org on 2012-07-22 05:13 +0200): 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. Ah, I had missed that the package went from m-a:same to m-a:foreign. At least that should make this a pretty rare occasion (hopefully). Thanks for the insights, Regards, Arno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682365: dpkg: native package in rc state prevents installation of m-a:foreign counterpart
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.2Windows API implementation - library ii libwine:i3861.4.1-1.2Windows 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). 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-2Windows API implementation - library ii libwine-bin:i386 1.4.1-2Windows 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? 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. Regards, Arno -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (900, 'stable'), (300, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dpkg depends on: ii libbz2-1.0 1.0.6-3 ii libc62.13-33 ii liblzma5 5.1.1alpha+20120614-1 ii libselinux1 2.1.9-5 ii tar 1.26-4 ii zlib1g 1:1.2.7.dfsg-13 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 0.9.7.1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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.2Windows API implementation - library ii libwine:i3861.4.1-1.2Windows 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-2Windows API implementation - library ii libwine-bin:i386 1.4.1-2Windows 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682365: dpkg: native package in rc state prevents installation of m-a:foreign counterpart
Hi, Guillem Jover wrote: On Sun, 2012-07-22 at 04:37:02 +0200, Arno Schuring wrote: dpkg: error processing /var/cache/apt/archives/libwine_1.4.1-2_i386.deb [...] rc libwine:amd64 1.4.1-1.2Windows API implementation - library ii libwine:i3861.4.1-1.2Windows API implementation - library [...] 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. How does crossgrading normally work? If Arno had not had libwine:i386 installed, would the upgrade have worked? [...] Yes, this appears to be a problem with apt, reassigning as such. What dpkg commands should apt run to upgrade from this state? Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682365: dpkg: native package in rc state prevents installation of m-a:foreign counterpart
On Sat, 2012-07-21 at 22:30:30 -0500, Jonathan Nieder wrote: Guillem Jover wrote: On Sun, 2012-07-22 at 04:37:02 +0200, Arno Schuring wrote: dpkg: error processing /var/cache/apt/archives/libwine_1.4.1-2_i386.deb [...] rc libwine:amd64 1.4.1-1.2Windows API implementation - library ii libwine:i3861.4.1-1.2Windows API implementation - library [...] 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. How does crossgrading normally work? Cross-grading happens whenever a new package instance is installed with a different architecture from the current single instance, as long as both old and new are not M-A:same, or they switch from non-M-A:same to M-A:same or the reverse. If Arno had not had libwine:i386 installed, would the upgrade have worked? Yeah (assuming not-installed == not-present), that would have been a cross-grade. Because the old one is M-A:same and the new one is M-A:foreign. [...] Yes, this appears to be a problem with apt, reassigning as such. What dpkg commands should apt run to upgrade from this state? In this particular case, apt would need to check that there's no multiple instances present if the new package is switching from M-A:same to non-M-A:same. And in that case notify the user that the package instance in config-files state would need to be purged. But I don't think apt would need to really learn about cross-grading to handle this particular case though, only when multiple instances are not allowed while installing a new version. thanks, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682365: dpkg: native package in rc state prevents installation of m-a:foreign counterpart
Guillem Jover wrote:
On Sat, 2012-07-21 at 22:30:30 -0500, Jonathan Nieder wrote:
What dpkg commands should apt run to upgrade from this state?
In this particular case, apt would need to check that there's no multiple
instances present if the new package is switching from M-A:same to
non-M-A:same. And in that case notify the user that the package instance
in config-files state would need to be purged.
Makes sense. Thanks for explaining.
This idea of purging one arch of a package while keeping other arches
is still new to me.
+ Most libraries' post-removal scripts run 'ldconfig' on removal and
do nothing on purge, which should work fine.
+ libc6.postrm purge runs db_purge. The corresponding 'owner' is
arch-qualified, making this safe.
+ Likewise for libpam0g, libpam-modules, libssl1.0.0, etc.
? libc6-i686.postrm remove and other optimized libc packages use
dpkg-query -l to find the version of all optimized libc packages.
The parsing does not take the colon in Multi-Arch: same packages
into account, so it never notices that all have been upgraded in
order to remove /etc/ld.so.nohwcap.
+ libgdk-pixbuf2.0-0.postrm is a model citizen.
+ libglib2.0-0.postrm purges some caches that are not
architecture-specific. This is probably harmless because they are
caches.
- libgphoto2-2.postrm purges .dpkg-bak files representing user
customized obsolete configuration files without checking if another
arch is staying around to take responsibility for them.
- libgtk-2.0-0.postrm purge wipes out /etc/gtk-2.0/*
- likewise for libgtk-3-0
- liblockfile1.postrm remove wipes out its documentation directory
(!)
- libpaper1.postrm purge removes /etc/papersize and the
corresponding ucf configuration
- libuuid1.postrm purge removes /var/lib/libuuid
- libwrap0.postrm purge removes /etc/hosts.{allow,deny}
- libzvbi0.postrm purge removes /etc/default/libzvbi0
Those are just the libraries I currently have installed on the machine
I am using to type this.
I guess a general bug is in order.
Jonathan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
