Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo

On Fri, Aug 26, 2016 at 11:00:22PM -0400, Doug Ledford wrote:

The most recent upstream libibverbs includes -fno-strict-aliasing
now so it can be dropped from the extra stuff in the Fedora spec
file.

Looking at strict-aliasing is the last build issue, I'd like to
minimize the places we turn it on, so if we have been shipping
libraries that never needed it I don't want to blanket enable
it. Ideally we could run with -fstrict-aliasing, but I realize how
hard that can be..

Do you know there are confirmed bugs without -fno-strict-aliasing?

2) Static libraries. Do we want to continue to provide these?

I'm ready to drop static libraries.

Great.

quoted

3) Version numbers. What version numbers do we give to the sub
   packages? I guess this is very distro specific.

You can not give different versions to sub-packages.  Or, allow me to be
more precise:  You can't use the Version: tag on sub-packages, it
resets

Okay, I should also clarify that when putting this all together I need
to consider Debian as well. I'm happy if RH wants to just use a jumbo
RPM, but that doesn't match Debian Policy regarding shared libraries
[my suggestions were informed by Debian Policy].

So I may look at deb packaging to guide the cmake install components
then, and try and get someone from the Debian community involved. I
started with RPM because that seems to be what most of our developers
use.

quoted

   I don't want to dictate what distros should do, but this is best
   done with support from the build system upstream, so some guidance
   on what to do is needed to finish the cmake stuff. (see #6)

I'm inclined to wrap it all up into a single package. librdmacm,
libibcm, libibumad, libibverbs, providers, all of it.

Okay, so just simple rdma-libs, rdma-utils, rdma-libs-devel works for
you? Nothing more to do then.

I would also be inclined to contribute the rdma scripts we have as
part of the package too.  I think some of them can use some cleanups
if they are going to become an upstream item instead of a RH
specific item, but otherwise they work well.  If I did that, I would
also welcome appropriate similar scripts for OSes that use different
tools than RH OSes.

This sounds like a good idea.

quoted

5) Valgrind - I've noticed CentOS forces valgrind on, and Debian

Agree.  Changing the default on this when present is good.

Will do.

quoted

7) NDEBUG - As upstream do we want this set or left unset for a
   release build. It eliminates all asserts and a few other things.
   I'm not sure what is being done today, but the %cmake rpmbuild
   default forces it on. (IMHO, upstream should decide this, not
   downstream?)

I think I would set this.  But I'm flexible.  Basically, I know end
users want Valgrind.  We've had multiple requests to enable it.
They

Okay, any thoughts on when assert should be enabled then? It is
useless to code it if we just compile it out in all builds.

Maybe non-packaging builds can default to leave assert in or
something?

quoted

9) libtool .la files. I preserved them, but if distros don't want them
   I'd love to ditch them.

Drop them.

Yay, I think debian agrees.

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