Ben Hutchings: > 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[0]). >>> >>> 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 >> installed? > > 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? X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git