Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> 1.10a is deemed (at least by automake and m4) to indicate a newer >> version than 1.10.1. counter-intuitive? This matters because >> sort --version now disagrees with that ordering: >> >> $ printf 'automake-1.10%s\n' .1 a|sort -V >> automake-1.10a >> automake-1.10.1 > > Sigh. I suppose we should get to the bottom of this. GNU tools should > agree on how to compare version numbers. Personally, I would have > expected the behavior of sort -V; I'm surprised that other tools > disagree. > >> This stems from the new gnulib filevercmp module. >> >> There's actually a minor dependency in coreutils on the >> newer automake. > > By "newer" do you mean "newer than 1.10.1"?
Yes. 1.10a is newer. > If so, do you recall which > post-1.10.1 feature is being used by coreutils? If that feature is Two things come to mind, but there may be more. Neither of these is a show-stopper: One change fixes a "make distcheck" failure. Another that is merely an optimization is the fact that it now relies on latest automake for efficient multi-file installation, i.e., install f1 f2 f3 ... destdir, rather than running install separately for each installed file. > important I suppose I should upgrade to automake 1.10a. (I assume 1.10a > refers the latest bleeding-edge version checked out from Savannah?) Yes. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
