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: 3116 bytes --]

On 8/25/2016 1:39 PM, Jason Gunthorpe wrote:
> On Thu, Aug 25, 2016 at 10:20:15AM -0400, Doug Ledford wrote:
>> On 8/23/2016 2:54 PM, Jason Gunthorpe wrote:
>>> On Mon, Aug 22, 2016 at 03:43:52PM -0600, Jason Gunthorpe wrote:
>>>
>>>> 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?

I would include a spec file, it just need not be complex.  So much of
what goes into one is distro specific, that there is a directly
proportional relationship between the complexity of the provided spec
file and chances that it will actually not be useful on anything other
than the one OS it was written on.

> How does upstream
> test the build infrastructure?

The downstream distros are really on the hook for that.  Making sure the
make/cmake build works well is our main goal.  The spec files and other
packaging files are templates, nothing more than that really.

> Are you saying the simple one .rpm is all we need?

Yep.

> Is that really
> useful to developers if it clashes with the distro packaging?

Yes.  It's likely that no matter what we do, there will be differences
between how distro package things up and how we do.  The developer will
need to manually uninstall the distro packages and then install the
package we provide.

> How do
> we test the build system parts that help the package splitting?

I wouldn't even go there :-)

> Isn't it easier for downstream to have recommended packaging to
> reference?

It is.  But they don't always follow it regardless.

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

We do.  But I was involved with the patches for the support and I was
still in charge of our packages at the time, so I knew.  But even if we
had updated the spec file in the tarball, it wouldn't have mattered.
Whenever we import a new package, part of the import is to create our
own spec file.  If there is a template, we might start from there, but
we essentially fork it immediately.  We have to in order to maintain our
own spec %changelog.  So changes to the template spec in the tarball
likely would have been missed just like the change to the configure script.


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