Reproducible builds are extremely useful. There are more benefits. For example, suppose you have a build server compiling software packages. If your builds are not reproducible and you want to debug a core dump, but you have no debug information, you are out of luck (well, you could dive into the assembly code, but it's inconvenient). If you want to keep debug information, you need to store them for every single build (what a waste of storage...) because the binary for each build is different. Not so with reproducible builds, you could simply check out the old version and compile it with debug information!
Another wonderful side effect: making it easier to change out other parts of the build infrastructure while being able to verify that you haven't broken anything. e.g. trying out experimental changes to ccache.
Most huge Debian packages carry a separate -debug package so you can get the symbols without huge recompilation times + having to set up a buildchain and associated dev libraries of all the packages.
If you're interested, the old way was to have an explicit -dbg package which often had to be requested, but now they can mostly autogenerated into -dbgsym packages. These are also uploaded to a separate archive these days too to keep the mirror sizes down.
I'm nitpicking here, but the convention is -dbg or (recently) -dbgsym as the suffix for packages in the Debian repositories. The Debain repository containing the debug packages itself itself is suffixed with -debug though, as in "unstable-debug".
Debug information often is choc-full of environment specific goodies that can easily cause builds not to be reproducible.
For example, debug information for several languages I've worked with embed the full path to where the source code file was originally compiled. This can easily vary across two machines in a way that when debug information is turned on, the builds are different, but when turned off they are the same.
You are correct, but to use a core file with debug info, the binaries don't have to be bit-perfectly identical. All that has to be equal is the offset of each function and statement and that is the case in reproducible builds. Debug info is only "tacked on"; you can strip a binary, generate a core dump and then use the original binary with debug information to debug the core dump.
While the reproducible builds efforts try to make builds path-independent, at the moment they often settle for reproducibility when built at the same common path. That's still enough that you can reproduce the build yourself.
Does path-independent mean what I think it means? One thing I hate about Linux is having to set prefix at build time. You can't tar up a software and move to your home directory on another machine. That and the lack of compatibility between base libraries/kernels means you can't hope to upgrade chrome for yourself easily like anyone on Windows or Mac can trivially do.
those kinds of differences are exactly part of what the reproducible builds project has worked on
however debug symbols and "debug mode" are two different things.. at least in debian packages are generally compiled with debug symbols on, then separated into a separate package automatically and stripped into the final package as a separate step.
