https://bugzilla.redhat.com/show_bug.cgi?id=1026337 --- Comment #18 from Kaleb KEITHLEY <kkeithle@xxxxxxxxxx> --- >> > 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 _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review