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.
--
John
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
