[rb-general] Bug#872263: linux-image-4.11.0-1-amd64-dbg: file overwrite error upgrading from stretch-backports

[Ben Hutchings]

On Tue, 2017-08-15 at 14:59 +0200, Andreas Beckmann wrote:
> Package: linux-image-4.11.0-1-amd64-dbg
> Version: 4.11.6-1
> Severity: serious
> User: debian-qa at lists.debian.org
> Usertags: piuparts
> Control: affects -1 + linux-image-amd64-dbg
> 
> Hi,
> 
> during a test with piuparts I noticed your package fails to upgrade from
> 'stretch-backports'.
> It installed fine in 'stretch-backports', then the upgrade to 'buster' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
> 
> See policy 7.6 at
> https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
> 
> > From the attached log (scroll to the bottom...):
> 
>   Selecting previously unselected package linux-image-4.11.0-1-amd64-dbg.
>   Preparing to unpack .../linux-image-4.11.0-1-amd64-dbg_4.11.6-1_amd64.deb ...
>   Unpacking linux-image-4.11.0-1-amd64-dbg (4.11.6-1) ...
>   dpkg: error processing archive /var/cache/apt/archives/linux-image-4.11.0-1-amd64-dbg_4.11.6-1_amd64.deb (--unpack):
>    trying to overwrite '/usr/lib/debug/.build-id/25/99e5c063eeb45c3b0068e66a8251a66f313afa.debug', which is also in package linux-image-4.11.0-0.bpo.1-amd64-dbg 4.11.6-1~bpo9+1

This filename is a hash of file contents, so this indicates that at
least one file was identical for the two builds.  Binary
reproducibility has bitten us in the ass!

We only create .build-id links for user-space code (vDSOs), so let's
compare those:

[linux-image-4.11.0-1-amd64-dbg_4.11.6-1_amd64.deb]
lrwxrwxrwx 1 ben ben 47 Jun 20 00:25 foo/usr/lib/debug/.build-id/22/1234d10e2a0342be17ce0b885f6fb4d8ea3330.debug -> ../../lib/modules/4.11.0-1-amd64/vdso/vdso32.so
lrwxrwxrwx 1 ben ben 47 Jun 20 00:25 foo/usr/lib/debug/.build-id/25/99e5c063eeb45c3b0068e66a8251a66f313afa.debug -> ../../lib/modules/4.11.0-1-amd64/vdso/vdso64.so
lrwxrwxrwx 1 ben ben 48 Jun 20 00:25 foo/usr/lib/debug/.build-id/66/ff5d513f55db31f2802e037593555810452e02.debug -> ../../lib/modules/4.11.0-1-amd64/vdso/vdsox32.so
4cdc4e5658ed934b8d3cfe22ddfe4aa1474acfddfc8a18a8a2c282f5bb0431be  foo/usr/lib/debug/lib/modules/4.11.0-1-amd64/vdso/vdso32.so
6e763e4f0677224b323164719495119c6d834a287a18c580a05eb2a3b5a2c1cf  foo/usr/lib/debug/lib/modules/4.11.0-1-amd64/vdso/vdso64.so
b8374d512446748311b333701bca11c5c8ed4c6140579d9c0de4e9d3b1a67821  foo/usr/lib/debug/lib/modules/4.11.0-1-amd64/vdso/vdsox32.so

[linux-image-4.11.0-0.bpo.1-amd64-dbg_4.11.6-1~bpo9+1_amd64.deb]
lrwxrwxrwx 1 ben ben 53 Jul  9 19:22 bar/usr/lib/debug/.build-id/25/99e5c063eeb45c3b0068e66a8251a66f313afa.debug -> ../../lib/modules/4.11.0-0.bpo.1-amd64/vdso/vdso64.so
lrwxrwxrwx 1 ben ben 54 Jul  9 19:22 bar/usr/lib/debug/.build-id/66/ff5d513f55db31f2802e037593555810452e02.debug -> ../../lib/modules/4.11.0-0.bpo.1-amd64/vdso/vdsox32.so
lrwxrwxrwx 1 ben ben 53 Jul  9 19:22 bar/usr/lib/debug/.build-id/6f/cb3e7c92bce418d52f5f5d6710222ae5377723.debug -> ../../lib/modules/4.11.0-0.bpo.1-amd64/vdso/vdso32.so
6dcde68bba7f9939cbc521eb262842011ed512ab473848fe94ea7d2639c6d839  bar/usr/lib/debug/lib/modules/4.11.0-0.bpo.1-amd64/vdso/vdso32.so
6e763e4f0677224b323164719495119c6d834a287a18c580a05eb2a3b5a2c1cf  bar/usr/lib/debug/lib/modules/4.11.0-0.bpo.1-amd64/vdso/vdso64.so
b8374d512446748311b333701bca11c5c8ed4c6140579d9c0de4e9d3b1a67821  bar/usr/lib/debug/lib/modules/4.11.0-0.bpo.1-amd64/vdso/vdsox32.so

So the amd64 vDSO and x32 compat vDSO are identical when built in
unstable and stretch-backports, but the i386 compat vDSO is not (for
some reason the debug filename mapping isn't being applied there).

>   Preparing to unpack .../linux-image-amd64-dbg_4.11+82_amd64.deb ...
>   Unpacking linux-image-amd64-dbg (4.11+82) over (4.11+82~bpo9+1) ...
>   Errors were encountered while processing:
>    /var/cache/apt/archives/linux-image-4.11.0-1-amd64-dbg_4.11.6-1_amd64.deb

We can probably work around this in src:linux by including the kernel
release string in the vDSO, so the backports build will always be
different.

Still, it seems like there is a wider problem here: if the exact same
code is ever built in two unrelated packages then their debug info
packages will conflict even if the regular binary packages don't.

Ben.

-- 
Ben Hutchings
Nothing is ever a complete failure; it can always serve as a bad
example.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20170816/3720a7f0/attachment.sig>