Here is how I thought I would do this: add a "diagnostic" subpackage that includes only the binary with the diagnostic build. There will be a file conflict only on the binary and users will have to look for the diagnostic subpackage to ascertain which build is executing.

On 08/14/2017 12:32 PM, Matthew Miller wrote: > On Mon, Aug 14, 2017 at 12:26:49PM -0400, John Dennis wrote: > >> Here is how I thought I would do this: add a "diagnostic" subpackage >> that includes only the binary with the diagnostic build. There will >> be a file conflict only on the binary and users will have to look >> for the diagnostic subpackage to ascertain which build is executing. >> > > Is it possible to package this so the diagnostic build is installed as > "/bin/foo-diagnostic" instead of "/bin/foo", with no conflicts? > I was trying to be too generic to address the larger issue. If the binary was an executable installed in a bin directory that would certainly be an option, probably also requiring the use of alternatives so that anything which invoked the executable could run unmodified. But in this specific case the binary is a loadable shared object (specifically an Apache module). The goal here includes ease of use and robustness. One could add a different module name but the user would have to adjust their module loading configuration, remember to reset their module loading configuration and there would have to be some some runtime check to prevent both modules from being simultaneously loaded which would cause catastrophic failures (I'm not even sure this runtime check is possible). Aside from Apache modules I believe the issues apply to any shared object or library where you might want two different versions with different runtime behavior and you don't want or can't modify the entire ecosystem that loads that shared object.

Take a look at the curl package and how it produces curl-minimal.