Re: Status of libpsm2
>>>>> "B" == Brian Smith <bsmith@systemfabricworks.com> writes:
B> On Tue, Mar 27, 2018 at 9:17 AM, "R" == Roland Fehrenbacher wrote:
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?
R> Yes, I think it should fail indeed. IMO, building the libfabric
R> package against libpsm2-2-compat doesn't make any sense. After
R> all, libfabric provides an abstraction of the low-level fabric,
R> so I can't see a use case where a compatibility layer should be
R> required when using it, or do you?
B> Agreed completely. My concern is that maintainers/users may build
B> other things down the road that depend upon
B> libpsm_infinipath.so.1, which will fail when libpsm2-2-compat's
B> version is the selected alternative. That situation may then
B> generate a bug against libpsm2.
B> Therefore, I wanted to get some consensus on the issue, and do
B> agree that the build should fail. I think it should be documented
B> somewhere, possibly d/README.debian?
Yes, IMO d/README.debian is the right place.
Cheers,
Roland
Reply to: