The drawbacks of the --symlink option

[Bruno Haible]

gnulib-tool's --symlink option may be useful for the very few people who
are constantly making changes in their package and in gnulib in parallel
(that means Paul and Jim). For other people, I think, however, the drawbacks
make this option not worthwhile:

  1) It introduces bugs when gnulib is updated (because through the symlinks,
     you get the changes in the lib/ and m4/ files, but you ignore those
     in the module description).
  2) "tar cfvz" creates a tarball which is not self-contained. It happened
     twice to me today: I created a tarball of coreutils, transferred it to
     another system for testing, and it didn't work because the symlinks
     which point to a partition not available on that other system.
  3) Other manipulations a maintainer normally does (chmod -R or others)
     might not work well with symlinks.

For these reasons, I change gnulib-tool's documentation (see below), and
I also change the 'gettextize' program so that copying files becomes the
default.

2006-10-08  Bruno Haible  <address@hidden>

        * gnulib-tool.texi: Emphasize the drawbacks of the --symlink option.

*** gnulib-20061007/doc/gnulib-tool.texi        2006-08-15 13:35:29.000000000 
+0200
--- gnulib-20061007-modified/doc/gnulib-tool.texi       2006-10-08 
14:32:52.000000000 +0200
***************
*** 90,97 ****
  neither is specified, the current directory is assumed.
  
  @code{gnulib-tool} can make symbolic links instead of copying the
! source files.  Use the @samp{--symbolic} (or @samp{-s} for short) option
! to do this.
  
  @code{gnulib-tool} will overwrite any pre-existing files, in
  particular @file{Makefile.am}.  Unfortunately, separating the
--- 90,103 ----
  neither is specified, the current directory is assumed.
  
  @code{gnulib-tool} can make symbolic links instead of copying the
! source files.  The option to specify for this is @samp{--symlink}, or
! @samp{-s} for short.  This can be useful to save a few kilobytes of disk
! space.  But it is likely to introduce bugs when @code{gnulib} is updated;
! it is more reliable to use @samp{gnulib-tool --update} (see below)
! to update to newer versions of @code{gnulib}.  Furthermore it requires
! extra effort to create self-contained tarballs, and it may disturb some
! mechanism the maintainer applies to the sources.  For these reasons,
! this option is generally discouraged.
  
  @code{gnulib-tool} will overwrite any pre-existing files, in
  particular @file{Makefile.am}.  Unfortunately, separating the