rdma-core packaging and multilib

rdma-core packaging and multilib

[Jarod Wilson]

We have some internal tools that check for multilib-clean packaging, and 
they're unhappy with ibacm:

Report from TEST_MULTILIB:
[BAD] [ibacm] Subpackage ibacm is not multilib-clean for x86_64 vs i686: 
2 files have non-equal 32/64bit content:
   /usr/share/man/man7/ibacm_prov.7.gz
   /etc/rdma/ibacm_opts.cfg

----8<----
ibacm_prov.7.gz on x86_64 vs i686:
...
-2. be installed under a configured directory, eg., /usr/lib64/ibacm;
+2. be installed under a configured directory, eg., /usr/lib/ibacm;
...
----8<----

Similar for ibacm_opts.cfg:

-# provider_lib_path /usr/lib64/ibacm
+# provider_lib_path /usr/lib/ibacm

Not sure what the ideal resolution is for this. I'd rather not put in 
the wrong path for one arch or the other, and I think lib64 isn't used 
universally by all 64-bit distros.

-- 
Jarod Wilson
jarod-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma-core packaging and multilib

[Jason Gunthorpe]

On Tue, Mar 14, 2017 at 02:02:15PM -0400, Jarod Wilson wrote:

> Report from TEST_MULTILIB:
> [BAD] [ibacm] Subpackage ibacm is not multilib-clean for x86_64 vs i686: 2
> files have non-equal 32/64bit content:
>   /usr/share/man/man7/ibacm_prov.7.gz
>   /etc/rdma/ibacm_opts.cfg

Yep

> ibacm_prov.7.gz on x86_64 vs i686:
> ...
> -2. be installed under a configured directory, eg., /usr/lib64/ibacm;
> +2. be installed under a configured directory, eg., /usr/lib/ibacm;
> ...
> 
> Similar for ibacm_opts.cfg:
> 
> -# provider_lib_path /usr/lib64/ibacm
> +# provider_lib_path /usr/lib/ibacm
> 
> Not sure what the ideal resolution is for this. I'd rather not put in the
> wrong path for one arch or the other, and I think lib64 isn't used
> universally by all 64-bit distros.

cmake substitutes in the correct path string at build time.

If you want these files to be identical then we cannot include the
path names at all, just put place holders and say to run 'ib_acme -D
. -O' to learn the configured value.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma-core packaging and multilib

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 2149 bytes --]

On 3/14/2017 2:17 PM, Jason Gunthorpe wrote:
> On Tue, Mar 14, 2017 at 02:02:15PM -0400, Jarod Wilson wrote:
> 
>> Report from TEST_MULTILIB:
>> [BAD] [ibacm] Subpackage ibacm is not multilib-clean for x86_64 vs i686: 2
>> files have non-equal 32/64bit content:
>>   /usr/share/man/man7/ibacm_prov.7.gz
>>   /etc/rdma/ibacm_opts.cfg
> 
> Yep
> 
>> ibacm_prov.7.gz on x86_64 vs i686:
>> ...
>> -2. be installed under a configured directory, eg., /usr/lib64/ibacm;
>> +2. be installed under a configured directory, eg., /usr/lib/ibacm;
>> ...
>>
>> Similar for ibacm_opts.cfg:
>>
>> -# provider_lib_path /usr/lib64/ibacm
>> +# provider_lib_path /usr/lib/ibacm
>>
>> Not sure what the ideal resolution is for this. I'd rather not put in the
>> wrong path for one arch or the other, and I think lib64 isn't used
>> universally by all 64-bit distros.
> 
> cmake substitutes in the correct path string at build time.
> 
> If you want these files to be identical then we cannot include the
> path names at all

That's not entirely true.  The man page specifically says the path in
the man page is an example, so it need not match the arch in use, it can
simply be one or the other with no substitution.  For the provider lib
path, it's in a comment, so again it would be possible to use proper
verbage to express that it is a sample and not use substitution.  We
might even be able to do something like:

# Modern distros commonly use either /usr/lib or /usr/lib64 for the
# default _libpath.  Substitute the correct value below before
# uncommenting
# provider_lib_path _libpath/ibacm

> , just put place holders and say to run 'ib_acme -D
> . -O' to learn the configured value.
> 
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: rdma-core packaging and multilib

[Jason Gunthorpe]

On Wed, Mar 15, 2017 at 12:34:37PM -0400, Doug Ledford wrote:
 
> That's not entirely true.  The man page specifically says the path in
> the man page is an example, so it need not match the arch in use, it can
> simply be one or the other with no substitution.  For the provider lib
> path, it's in a comment, so again it would be possible to use proper
> verbage to express that it is a sample and not use substitution.  We
> might even be able to do something like:
> 
> # Modern distros commonly use either /usr/lib or /usr/lib64 for the
> # default _libpath.  Substitute the correct value below before
> # uncommenting
> # provider_lib_path _libpath/ibacm

Debian derived uses /usr/lib/x86_64-linux-gnu

I think change the man page like:

       To add a provider to the ibacm core service, the provider must

       1. be implemented as a shared library;

       2. be installed under the configured directory, (see the output
       of ib_acme -D . -O)

       3  export a function provider_query() that returns a pointer to its provider info
          and version info.

And something similar for the etc file? The RH spec file produces the
etc file by running the ib_acme command, so it should sedscript in the
right text..

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html