Hi Helmut, you're quick!
On 2022-12-12 15:17, Helmut Grohne wrote: > Package: libcap-dev > Version: 1:2.63-1 > Severity: serious > Jutsification: fails to install with an unpack errror > User: helm...@debian.org > Usertags: rebootstrap > > Coinstalling libcap-dev fails: > > | Unpacking libcap-dev:amd64 (1:2.63-1) ... > | dpkg: error processing archive > /var/cache/apt/archives/libcap-dev_1%3a2.63-1_amd64.deb (--unpack): > | trying to overwrite shared '/usr/lib/libcap2/tests/cap_test', which is > different from other instances of package libcap-dev:amd64 > | dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) > | Errors were encountered while processing: > | /var/cache/apt/archives/libcap-dev_1%3a2.63-1_amd64.deb > | E: Sub-process /usr/bin/dpkg returned an error code (1) I noticed this myself only too late -- lintian flagged all of these errors, but I had a bug in my workflow, and only source package checks were performed. > I suppose that the test binaries were recently added to the -dev > package. There are basically three ways of dealing with this: > > a) Drop Multi-Arch: same. This is a little inconvenient for some users, > but is really something we can do. Most cross builds will continue > working in the absence of Multi-Arch: same. > > b) Move those test binaries to architecture-dependent paths. This is what I did whilst preparing the 2.66 upload. I was going to wait for 2.63 to migrate, but might as well just push that now. > c) Move those test binaries to a different package. An obvious candidate > would be a new package libcap-tests. Prior art: dbus-tests. If you > do, it would be awesome to support the noinsttest build profile. Thanks for the prior art on that, I was unsure how to handle that. It definitely feels cleaner than shipping this with libcap-dev. I'll wait for 2.66 to migrate to testing first. Best, Christian
