On 07/27/2017 06:23 AM, James Youngman wrote: > Looking at the patch, it looks not terribly burdensome to maintain > "downtream" except for the possibility that some fts option could > subsequently be introduced in gnulib which shares a value with > FTS_NOLEAF. > > Paul, since you don't plan to apply this patch upstream, do you have > any suggestions for ensuring that we avoid collision or maintenance > problems with the downstream patch?
As long as we maintain the patch in diff, then gnulib-tool will tell us (any time we update git submodule for gnulib) whether we have to regenerate the diff, at which point we can cater to a new option by bumping our value for FTS_NOLEAF. Here's an example of coreutils storing its project-local diffs to upstream gnulib: http://git.sv.gnu.org/cgit/coreutils.git/tree/gl/lib/tempname.c.diff -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
