On 11/14/2011 04:04 AM, Gary V. Vaughan wrote: > This series of changesets are either necessary for, or at least > make the application of the directory move patches coming in the > next set as straight forward as possible. > > It turns out that we haven't needed to fork a tar process for > every file-copy for about 4 years now. With that knowledge it's > easy to reduce the complexity of the surrounding functions > somewhat. > > I'll apply in 72 hours, along with addressing any feedback I > get in the mean time. > > @@ -112,8 +110,7 @@ M4SH_GETOPTS( > CP="func_echo_all $CP" > test -n "$LN_S" && LN_S="func_echo_all $LN_S" > MKDIR="func_echo_all $MKDIR" > - RM="func_echo_all $RM" > - TAR="func_echo_all $TAR"], > + RM="func_echo_all $RM"],
My only concern is whether existing projects may have been (inadvertently) relying on $TAR to be set on their behalf by using libtool. The reason I ask is that I know of at least one case where a project was using libtool, but manually setting $RM itself to a value different than libtool's default, which in turn caused libtool to emit a warning: http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=8a93dafc5 That is, dropping $TAR is a user-visible change, so we either need to document it in NEWS that it is intentional, or we need to keep providing $TAR (even though we no longer use it) to keep our namespace pollution constant, all so that users upgrading to newer libtool don't complain about an undocumented change. -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature