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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
