>>>>> "B" == Brian Smith <bsmith@systemfabricworks.com> writes:
B> The alternatives patch from infinipath-psm has been incorporated
B> into libpsm2. I recompiled libfabric1 with psm2 support and was
B> able to use psm and psm2 providers with fabtests-1.5.3
B> (https://github.com/ofiwg/fabtests ) and openmpi-2.1.1-8.
B> One issue that arose is that having libpsm2-2-compat 's
B> libpsm_infinipath.so.1 selected while building libfabric1 caused
B> the build to fail (no dependencies in
B> libpsm_infinipath.so.1). libpsm_infinipath.so.1 was excluded from
B> dh_makeshlibs because I saw it as a "plugin". I changed libpsm2
B> d/rules to generate dependencies for libpsm_infinipath.so.1, and
B> libfabric1 can now build against it.
B> However, it seems like a bad idea to build against a
B> compatibility library. Perhaps, the dependent build *should*
B> fail. Thoughts?
Yes, I think it should fail indeed. IMO, building the libfabric package
against libpsm2-2-compat doesn't make any sense. After all, libfabric
provides an abstraction of the low-level fabric, so I can't see a use
case where a compatibility layer should be required when using
it, or do you?