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

On Thu, Aug 25, 2016 at 02:13:06PM -0600, Jason Gunthorpe wrote:

On Thu, Aug 25, 2016 at 03:52:46PM -0400, Jarod Wilson wrote:

quoted

On Thu, Aug 25, 2016 at 11:39:16AM -0600, Jason Gunthorpe wrote:

quoted

On Thu, Aug 25, 2016 at 10:20:15AM -0400, Doug Ledford wrote:

quoted

On 8/23/2016 2:54 PM, Jason Gunthorpe wrote:

quoted

On Mon, Aug 22, 2016 at 03:43:52PM -0600, Jason Gunthorpe wrote:

quoted

The full install to / is still a small TODO, it is part and parcel
with doing the packaging, in my mind.

I just pushed a basic starting point rpm spec file, it still needs to
be split into multiple subpackages, but it is installable with all the
usual paths.

You can do that, but I routinely tell upstream maintainers that we don't
touch their spec files.  Every distro modifies the spec file so heavily
for their own custom installation that it just doesn't make much sense
to worry about it at the upstream level.  Build one that can be used
when running rpmbuild -ta and that's all you need.

I'm not sure I understand your comment.

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.

quoted

quoted

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.

A good downstream ought to be reporting any issues they encounter, so I
think you can more or less offload that burden until such time as someone
comes and says "hey, you just broke xyz".

quoted

I either build locally in the git tree(s) and run from there, or I take
the upstream tarball and modify my distro spec file to use it.

We've never been able to run the rdma stack from the build trees, the
dlopen stuff and the split packaging made it too hard. We can almost
do it with the unified tree, but that is still a few patches away.. So
that isn't a good answer for developers.

I usually rpmbuild and install libs, run various test apps, etc., from
local git tree builds (perftest, librdmacm utils/examples, etc).

quoted

Generally, no, because various upstreams often do things that violate the
packaging rules for a given distro. Upstream specs are occasionally used
for reference bringing up a new package, but at least for Red Hat
and

Well, that is exactly where we are right now, bringing up a new
(complex) package.

I think the only really complex part is splitting it into sub-packages
correctly, which is mostly getting %files lists, Provides and Obsoletes
right, from the rpm perspective.

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.

quoted

quoted

Eg I think it was a dis-service to other distros not to update the
reference verbs spec file with the libnl dependency. I wonder how many
downstreams noticed this change and are still building verbs properly?

Add the dependency to the build infra, and problem solved for rpm, deb,
whatever other packaging system. Updating the spec only helps rpm-based
distros, maybe, if they use the spec (which RH/Fedora doesn't).

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?

Downstream folks should be reviewing release notes at the very least, and
preferably, upstream source code management commit logs, to have a clue
what they're packaging up. I'm sure not all do though.

-- 
Jarod Wilson
jarod-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org

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