On Mon, 2017-10-02 at 12:38 -0400, J. Bruce Fields wrote: > On Mon, Oct 02, 2017 at 10:03:06AM -0400, Steve Dickson wrote: > > > > > > On 09/14/2017 10:02 AM, Justin Mitchell wrote: > > > It was suggested that merging the trees is more desirable than splitting > > > the common code out into a shared library, so this patch set attempts to > > > merge the libnfsidmap code into nfs-utils. > > > > > > The main body of the code, copyright notices, and readme are copied > > > across, omitting the shared conffile code, and trimming unused files > > > like strlcpy.c and queue.h. The build files of both are adjusted to the > > > new structure, and the dependent nfs-utils now link to the included > > > shared library instead of an external one. > > > > > > The source libnfsidmap tree did include some packaging files for > > > debian/dkpg which have been omitted, there are no packaging materials in > > > nfs-utils to merge them with, and i welcome advice on what should be > > > done here. > > > > > > Change: libnfsidmap imported as support/nfsidmap/ > > A quick status on this... I'm working on this but this patch is going > > to cause a packaging nightmare... since the libnfsidmap package is > > required by nfs-utils which now is installing that lib... so > > this might take some time... > > Would it help to start by keeping the separate libnfsidmap rpm, but just > building it from nfs-utils instead of from separate source? The BuildRequires for libnfsidmap is no longer necessary, as when you configure and build nfs-utils from the top it will automatically build and link to the merged libnfsidmap code. I would expect then to list libnfsidmap as a sub-package within the nfs-utils spec file so that the end result is the same set of rpms out as we had before the merge. Neither source tree contained any rpm packaging materials otherwise I would have adjusted and tested it as part of the patch set. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
