[Bug 1026337] Review Request:=?UTF-8?Q?=20nfs=2Dganesha=20=E2=80=94=20a=20user=2Dmode=20file=20server=20for=20NFS=20?=(v3, 4.0, 4.1 pNFS)

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1026337



--- Comment #18 from Kaleb KEITHLEY <kkeithle at redhat.com> ---
>> > Build issue aside, I find it hard to justify how including this library 
>> > doesn't violate https://fedoraproject.org
>> > /wiki/Packaging:No_Bundled_Libraries. You said that "it'll be split out when > ready", but actually is seems to be
>> > a totally separate project. I'd approve the package as is, otherwise.
>> 
>> Well, then we need an exception I guess. A) It's not really bundled, or I
>> don't understand your definition of bundled. It's a static lib used during
>> the build, not installed or even in the RPM,
>It is bundled, in the sense that this project A contains a snapshot of project B as part of it's sources.
>So if B makes a new release independently from A, than our compiled A will be stuck with the old version.

libntirpc != libtirpc. I'll change it to libnfsganesharpc.a Does that make it 
better?

>> B) Upstream isn't ready to
>> package it separately because they haven't settled on the final APIs and at
>> the present time they are the only consumer of it. Its git repo is, at
>> present, still a part of the nfs-ganesha project on github.
>OK, this is the crucial information I was missing. This information was >obscured by the Source1 link
>not being a link to upstream. In this case bundling them could be OK, if it
>was really one project in two tarballs. But I don't think that's really the case.
>Even if nfs-ganesha is the new upstream for libntirpc, libntirpc has been packaged
>for redhat and other distributions. 

That's not true. As I alluded to above, you're probably thinking of libtirpc.

> So we have a situation where it was a separate
> project, is packaged separately, and is intended to be separate in the future, so it's
> very hard to argue that it is part of the nfs server.

At present that actually is the case.

> If can apply for an exception, but I think it's unlikely to pass. And I'm *quite* sure
> that making a second package will be faster than waiting for Fesco.

Upstream are quite clear that they do not want separate packaging at this time.

> > And C) if the
>> license was incompatible I could definitely understand it, but since it's
>> BSD then I don't see the license as an issue.
>> > nfs-ganesha.src:62: W: rpm-buildroot-usage %prep %cmake -DCMAKE_BUILD_TYPE=Maintainer -DBUILD_CONFIG=everything -DCMAKE_INSTALL_PREFIX=%{buildroot}/usr ./src
>> > Yeah, %cmake step should be moved to %build.
>> >
>> > [!]: Package must own all directories that it creates.
>> >     Note: Directories without known owners: /usr/share/doc/nfs-ganesha-2.0.0
>> > Directory ownership is missing.
>> 
>> Not sure what the fix is for this. I made a WAG.
> Hm, I'm not sure what a WAG is, but it should be enough to just add
> '%dir /usr/share/doc/nfs-ganesha-2.0.0/' to '%files docs'.
> 
> I see that I missed one more thing: https://fedoraproject.org/wiki/Changes/UnversionedDocdirs.
> Basically, if you use %{_pkgdocdir} as the documentation directory, things > should work in F >= 19.
> I'm not sure though how this macro will work out with the single docs directory, you might have to adjust
> to keep -docs docs in the same directory as main package docs.

new files at 

Spec URL: http://kkeithle.fedorapeople.org/update-7/nfs-ganesha.spec
SRPM URL:
http://kkeithle.fedorapeople.org/update-7/nfs-ganesha-2.0.0-0.rc3.fc19.src.rpm

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component