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

[Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 3484 bytes --]

On 8/25/2016 4:13 PM, Jason Gunthorpe wrote:
>>> Are you saying we don't need a specfile in upstream?
>>
>> Distros certainly don't require it.
> 
> I know that, my question is poised to the larger developer community
> who need to build test and deploy this stuff as not-a-distro.

Developers like to do things that driver packagers nuts ;-)  For the
larger developer community, a decent set of default options for make
install in the repo itself is the main thing I think.

>>> How does upstream
>>> test the build infrastructure?
>>
>> ./configure, make, make install (or cmake/ninja/whatever)
> 
> rpmbuild does stuff that needs to be checked out and validated by
> upstream at least occasionally, or packaging becomes too hard for the
> downstream because of broken build infra.

Given that rpmbuild is basically nothing more than a scripted build
session, as long as the make/cmake system works well, so will rpmbuild.
The main things that cause problems for distros when upstream does it
are things like using rpath to search alternate library locations.  It
makes sense to a developer.  She can have multiple installed copies of
the code and test different versions this way.  For a distro though,
that's a major security issue as rpath searches by a distro installed
library can be exploited by black hats behind the user's back.  So we
forcefully rip those out.  Those are the sorts of things that are more
likely to crop up.  But, as Jarod mentioned, we don't need to worry
about this too much.  If something breaks, the distros will speak up.

> We've never been able to run the rdma stack from the build trees,

It's possible...you just have to do every step in the right order ;-)  I
had a spreadsheet that I tracked packages, versions, build states,
install states, and dependencies.  Made things a lot easier.

But I get your point.

> 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.

I have no doubt that we have plenty of spec file expertise on hand to
make a reasonable starting spec file for the repo.  We'll need someone
else's help though for the non-rpm stuff.

> The build infra has an optional requirement for libnl3, and other
> things.
> 
> I don't know why we did that, maybe it should have been mandatory, but
> the point remains, it is a subtle change that is easy to miss
> downstream. Presumably downstream folks review changes to the tarball
> including the reference spec file before packaging a new version?

They should review things, but stuff can slip through the cracks.  Since
libnl3/libnl is needed for RoCE, and it's possible to build libibverbs
as something useful for IB and ignore RoCE, the libnl3/libnl requirement
shouldn't be mandatory.  However, in order to make it very explicit
since I suspect most people want RoCE support and might not realize they
are missing a build requirement for it to work, the tests in the
configure script could be changed to add a new feature "RoCE Support
(default: yes)" and make the libnl3/libnl test be part of the RoCE
support, and if it isn't present, fail.  Then people have to turn off
RoCE to build it without libnl3/libnl.  That would be more effective of
a configure setup I think.


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: 0E572FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]