On Mon, Aug 14, 2017 at 10:50 AM, John Dennis <jdennis(a)redhat.com> wrote:
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
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.
Have you looked at COPR ( https://copr.fedorainfracloud.org/
)? It sounds
like this could potentially be a good use case for that?