Re: [rb-general] Bug#872263: linux-image-4.11.0-1-amd64-dbg: file overwrite error upgrading from stretch-backports
> On Wed, 2017-08-16 at 17:51 +0000, Daniel Shahaf wrote:
>> Chris Lamb wrote on Wed, 16 Aug 2017 07:54 -0700:
>>>> 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.
>>> I've seen this outside of reproducibility where I was shipping the exact
>>> same binary in the redis-server and redis-sentinel packages (it changes
>>> behaviour based on argv).
>>> The -dbgsym packages then conflicted for the same reason.
>> Stupid question, but why _do_ the packages conflict? Couldn't the
>> package manager notice that the file versions that would be installed by
>> each package are equivalent [= same name, chmod, and bit-by-bit
>> contents], and keep the file existing so long as _either_ package is
> In the case of the kernel packages, the identical binaries (vDSOs) are
> emebedded in kernel images with different filenames. The identical
> debug info is installed with different filenames. But the symlinks to
> them underneath /usr/lib/debug/.build-id therefore have the same (hash-
> based) name and *different* content.
Could you reverse the symlink? So the target (the actual file) is in /usr/lib/debug and so both packages will have the same file installed at that path.
Then perhaps we could ask dpkg to add an exception for this Breaks/Replaces annotation for files under /usr/lib/debug when the file contents are the same (or just blanket-allow this case for all paths).
When the policy was originally written it would have taken extra technical effort to refcount which packages referred to the same file+filepath, but (IIRC) this logic has since been added in order to deal gracefully with Multi-Arch. Maybe it's time to extend it to more things?