* TODO: Removed obsolete comments about RMS' package system.

diff --git a/ChangeLog b/ChangeLog
index ebebecf731e27f432534e374890fd0b518d38689..5dcb39c83f7dad238b4a4cdc5681d93e788fff37 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2002-03-16  Gary V. Vaughan  <gary@gnu.org>
+
+       * TODO: Removed obsolete comments about RMS' package system.
+
 2002-03-07  Albert Chin-A-Young  <china@thewrittenword.com>
 
        * libtool.m4: Allow LT_AC_PROG_SED to work under autoconf

diff --git a/TODO b/TODO
index aed518aea08e59b17afced8ba952de365c92d0ac..2a3072e030eb15f44cfbb188071886a7728fe887 100644 (file)
--- a/TODO
+++ b/TODO
@@ -7,7 +7,7 @@ In the near future:
 * Fix the following bugs in libltdl:
  - Report dlerror() for dlclose and dlsym if available
  - Make sure that the dependency_libs of a dlpreopened module won't be loaded.
- 
+
 * Check whether the version of libtool.m4 is compatible with
 ltconfig/ltmain.sh.  Meanwhile, the recommended approach for
 developers using automake is to insert libtool.m4 in acinclude.m4.
@@ -55,8 +55,8 @@ respective ltdl.m4 macros.
 
 * Godmar Back writes:
   libltdl uses such stdio functions as fopen, fgets, feof, fclose, and others.
-  These functions are not async-signal-safe. While this does not make 
-  libltdl unusable, it restricts its usefulness and puts an 
+  These functions are not async-signal-safe. While this does not make
+  libltdl unusable, it restricts its usefulness and puts an
   unnecessary burden on the user.
 
   As a remedy, I'd recommend to replace those functions with functions
@@ -66,7 +66,7 @@ respective ltdl.m4 macros.
   out from which you can steal the latter.
 
   I believe relying on async-signal-safe functions to the greatest extent
-  possible would greatly improve libltdl's ability to be embedded in and 
+  possible would greatly improve libltdl's ability to be embedded in and
   used by other systems.
 
 * Arrange that EXEEXT suffixes are stripped from wrapper script names
@@ -146,13 +146,6 @@ properly with AC_CONFIG_AUX_DIR using projects.
 Things to think about:
 **********************
 
-* Talk with RMS about his so-called `automatic package generation
-tool.'  This is probably what Thomas has been murmuring about for the
-Hurd.  We'll need to integrate package-supplied programs such as
-libtool into that scheme, since it manages some of the preinstall and
-postinstall commands, but isn't installed itself.  Probably, things
-like libtool should be distributed as part of such a binary package.
-
 * Maybe implement full support for other orthogonal library types
 (libhello_g, libhello_p, 64 vs 32-bit ABI's, etc).  Make these types
 configurable.