Thread (1 message) 1 message, 1 author, 2016-08-25

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

From: Jason Gunthorpe <hidden>
Date: 2016-08-25 20:13:06

On Thu, Aug 25, 2016 at 03:52:46PM -0400, Jarod Wilson wrote:
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
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.
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.
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.

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

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help