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

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

On Fri, Aug 26, 2016 at 11:42:06AM -0400, Jarod Wilson wrote:

> > Would you help making a spec file that is close to what you
> > could use in the distro? I don't really care if it is stored in the
> > package or stored inside RH, but we need to get one made.
> 
> Sure. It would probably be something to route through Fedora first though,
> and I don't own all the packages this would encompass in Fedora, but could
> certainly round a few people up and help out.

Sounds good, here are my thoughts let me know what you think:

1) Compiler flags/etc. I haven't audited all the CentOS rpms, but at
   least verbs overrides the compiler flag to set -fno-strict-aliasing
   Upstream should be distributing the package in a way that works, so
   downstream should not need do this. We need to decide if we want/need to
   force no-strict-aliasing or not, or use some kind of compiler
   test or whatever.
2) Static libraries. Do we want to continue to provide these? Looking
   at it, I'm skeptical that libibverbs works at all as a static, does
   anyone know? Particularly, how does it work? Should we get rid of
   it or do more work to try and make it work sanely. (eg a
   libibverbs.a that includes all the providers or something)
3) Version numbers. What version numbers do we give to the sub
   packages? I guess this is very distro specific.
4) Package split. I'm suggesting
    libibcm1 -devel -static
    libibumad3 -devel -static
    libibverbs1 -devel -static
    librdmacm1 -devel -static
    rdma-utils (all the other random binaries and stuff)
    ibverbs-plugins (all the providers)

   So we would get rid of the individual packages for the providers.
   There would be no -devel for the providers and the static providers
   would be bundled with libibverbs1-static

   IMHO this is more inline with common distro practice for packaging
   plugins. (most providers are about 20k-30k)

   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)
5) Valgrind - I've noticed CentOS forces valgrind on, and Debian
   leaves it as the upstream default (off)
   IMHO Upstream should shift to use valgrind by default if available
   and encourage all downstreams to compile it with valgrind headers
   present.
6) Actually splitting the file list. cmake has a INSTALL COMPONENT
   facility to help with this, but it needs to be setup upstream.
   Other than the include files and man pages this is straightforward
   to do from the spec file
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?)
8) COPYING file and other doc stuff. There are 4 different licenses
   being used in the source. Everything is GPLv2 however. I think this
   only impacts the providers.
9) libtool .la files. I preserved them, but if distros don't want them
   I'd love to ditch them.

I'd like to get thing in a state where it is not painful for the
distros to transition - to ease things along.

My approach has been to faithfully preserve exactly what we do today,
and the list above is basicly my list of things that seem like they
need attention.

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