Scenario: A previously shipping RPM has the capability to be built with diagnostic and other debugging features. This has always been turned off and should be turned off for any production deployment. However the ability to install a version of the package with these features enabled would be immensely useful.
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.
What is the best way to add alternate builds in an RPM? Do we have existing precedent? I didn't find any guidance in the packaging guidelines, the closest I could find was the "Conflicts" doc (https://fedoraproject.org/wiki/Packaging:Conflicts) which didn't really address the issue.
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?
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.
On Mon, Aug 14, 2017 at 10:50 AM, John Dennis jdennis@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 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.
Have you looked at COPR ( https://copr.fedorainfracloud.org/ )? It sounds like this could potentially be a good use case for that?
On Mon, 14 Aug 2017 12:26:49 -0400 John Dennis jdennis@redhat.com wrote:
Scenario: A previously shipping RPM has the capability to be built with diagnostic and other debugging features. This has always been turned off and should be turned off for any production deployment. However the ability to install a version of the package with these features enabled would be immensely useful.
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.
What is the best way to add alternate builds in an RPM? Do we have existing precedent? I didn't find any guidance in the packaging guidelines, the closest I could find was the "Conflicts" doc (https://fedoraproject.org/wiki/Packaging:Conflicts) which didn't really address the issue.
Take a look at the curl package and how it produces curl-minimal.
Paul.
On 08/14/2017 01:27 PM, Paul Howarth wrote:
Take a look at the curl package and how it produces curl-minimal.
This sounds close to what I was trying to accomplish.
It uses the new RemovePathPostfixes RPM directive which was made available in rpm 4.13.0 released on 11/3/2016.
It was documented in this blog: http://www.pixelbeat.org/docs/conflicting-rpms.html
The original discussion appears to have begun with this thread: https://lists.fedoraproject.org/pipermail/devel/2015-November/216965.html
Unfortunately there was an issue with debuginfo packages, but it looks like fix was added upstream a few days ago: https://github.com/rpm-software-management/rpm/issues/280
I had never heard of RemovePathPostfixes before. I couldn't find any useful documentation on it's behavior. Given how new it is and the fact rpm 4.13.0 won't show up in RHEL until RHEL 8 makes it kind of a non-starter for me.
I'm beginning to believe RPM is not well suited to this and my best option is to just run two builds and name the .so differently and let the user deal with loading the right .so based on it's name.
On 08/15/2017 12:08 AM, John Dennis wrote:
On 08/14/2017 01:27 PM, Paul Howarth wrote:
Take a look at the curl package and how it produces curl-minimal.
This sounds close to what I was trying to accomplish.
It uses the new RemovePathPostfixes RPM directive which was made available in rpm 4.13.0 released on 11/3/2016.
It was documented in this blog: http://www.pixelbeat.org/docs/conflicting-rpms.html
The original discussion appears to have begun with this thread: https://lists.fedoraproject.org/pipermail/devel/2015-November/216965.html
Unfortunately there was an issue with debuginfo packages, but it looks like fix was added upstream a few days ago: https://github.com/rpm-software-management/rpm/issues/280
I had never heard of RemovePathPostfixes before. I couldn't find any useful documentation on it's behavior. Given how new it is and the fact rpm 4.13.0 won't show up in RHEL until RHEL 8 makes it kind of a non-starter for me.
I'm beginning to believe RPM is not well suited to this and my best option is to just run two builds and name the .so differently and let the user deal with loading the right .so based on it's name.
I might say something stupid but what prohibits you to create a separate "diagnostic" package ( as you have proposed ) and use alternatives to point the actual loaded file to the one intended at the time of load ? AFAIK there is no rule specifying that alternatives can be used for /bin or binaries only. It's a just a mechanism of manipulating symlinks via a central repository. Install the debug-enable .so with a different name ( or in a different place ), point the symlink to either it or the default ( and with higher alternatives priority ) library, make apache use the symlink rather than the lib directly and you are done.
You will need to make users aware of the way to use it and that would be all. That is, unless I am mistaken in which case I will be glad to stand corrected and learn.
packaging@lists.fedoraproject.org
-
Dave Johansen -
John Dennis -
Manuel Wolfshant -
Matthew Miller -
Paul Howarth