Gnulib isn't forward or backwards compatible with itself, so trying to build a project using gnulib pretty much requires everyone to know which gnulib revisions were used. There is no infrastructure to solve that problem easily today, therefor at least all project that I'm familiar with, that uses gnulib, do commit the gnulib files into CVS. This makes sure everyone use the same gnulib code that the code was written for.
Well, I was talking with Meyering about this, and parted, and coreutils don't do keep a checked in copy of gnulib. Also, from the looks, bootstrap fetches gnulib from CVS directly (if you want). The problem that I experienced today was that I had recent auto* tools, but the gnulib in CVS was old. We don't keep auto* generated scripts in CVS, so this just causes problems in keeping a set of generated tools updated, but not the another set. I don't see the backward/forward compatibility stuff as a problem, if you have a working gunlib and auto* that work with the gnulib version you have, then you won't get any problems. The problem of backward/forward compatibility only occurs if you have a outdated version of auto* or gnulib; and if you update gnulib on your machine, then I think one can assume that you will update auto* in the same go. And anyway, this backward/forward compatibility stuff will would happen right now since we don't know what version of auto* everyone uses, you might be using 2.59, and I might be using 2.61; but in either case you'd have a copy of gnulib that works with 2.59, and I'd have a gnulib copy that works with 2.61. Cheers! _______________________________________________ Bug-inetutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-inetutils
