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