Hey, On Tue, Jan 17, 2017 at 12:30:04PM +0100, Adam Borowski wrote: > On Tue, Jan 17, 2017 at 12:11:42PM +0100, Evgeni Golov wrote: > > On Tue, Jan 17, 2017 at 10:50:55AM +0100, Adam Borowski wrote: > > > > I have a system with both libpam-modules:amd64 and libpam-modules:i386 > > > > installed on upgrade it failed with > > > > > > > dpkg: error processing archive > > > > /var/cache/apt/archives/libpam-modules_1.1.8-3.1+deb8u2_i386.deb > > > > (--unpack): > > > > trying to overwrite shared '/usr/share/man/man8/pam_unix.8.gz', which > > > > is different from other instances of package libpam-modules:i386 > > > > dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) > > > > > > > > I removed the conflicting man page and also pam_exec.8.gz then ran > > > > apt-get > > > > install and it continued with the upgrade > > > > > > Yeah, that's the same as #851650. My fix was to move the xsl stack from > > > Build-Depends-Indep to Build-Depends, as man pages are included in > > > non-indep > > > packages as well. > > > > > > No one likes breakage in stable, but NMUing an essential package in stable > > > is not something to take lightly. I guess Evgeni, who did the last NMU, > > > might know more. > > > > Let me be very honest: that NMU was only done because I was really > > annoyed with the bug and nobody seemed to fix it otherwise. > > Yeah, I'm not accusing you of breaking it; the problem here is that a bug > unrelated to what you did makes the package unupgradeable (without jumping > through hoops) on multiarch setups.
No worries, did not read any accusation into it. Shouldn't the package be as broken as it was before in regards to that? Both 1.1.8-3.1+deb8u1 and 1.1.8-3.1+deb8u2 had the same set of binaries in the original upload (and then i386 built by buildds). Or maybe I am misunderstanding the issue here. > > The fix was tested in unstable (like yours) and in Ubuntu for a long > > time, but I did not have any tests outside of the specific codepath I > > touched. > > I guess the core problem here is that we have a non-trivial essential > package that's not seeing enough tuits: five NMUs in a row in unstable, > yours in stable (plus a DSA). In a random shit package I wouldn't hesitate, > but here it needs some thinking+communicating first. Totally agreed that pam needs a maintainer.
