[EMAIL PROTECTED] (Karl Berry) writes: > But nowadays my understanding is that coreutils, and > every other project, uses gnulib-tool.
The problem occurs even when gnulib-tool is being used. A common way for developers to use gnulib-tool, which I use in many projects (not just coreutils), is something like this: ./bootstrap --gnulib-srcdir=../gnulib This invocation of "bootstrap" uses gnulib-tool but bootstraps off of symbolic links to my local copy of gnulib, which is much faster than pulling a gnulib copy from the Savannah CVS. More important, it lets me bootstrap from a modified version of gnulib before committing the gnulib changes to CVS. If this sort of bootstrap were changed to make copies rather than symbolic links, it would be much more of a pain to develop when changes to both gnulib and an application are being debugged. It would be far too easy to mistakenly edit the coreutils copy of a gnulib file rather than the original; and later, when everything is checked in, some of the gnulib fixes would be lost. I speak from sad experience here, because that is the way I used to develop, before I started using symbolic links. It was a real pain. Going back to using copies (instead of symbolic links) when bootstrapping would not merely be a minor annoyance for me; it would be a real hassle and would make the resulting programs less reliable. I hope this helps to explain the technical considerations better. > I know of no other extant example of licenses being manifestly converted Me neither. But gnulib is special in many ways.
