Paul Eggert wrote:
> >> > 1) now, the appended patch,
> >> > 2) in a year, change modules/stdbool to require gl_STDBOOL_H,
> If we do (2) now, people will still have two
> years to change their code, no? What is the practical difference
> between the schedule you originally proposed, and a schedule that
> consists of doing (1) and (2) now, but (3) two years from now?
I'm trying to be over-cautious, and it's hard to justify, if you assume
everyone follows the official procedure of using gnulib. A fact that I
discovered while maintaining 'gettextize' is that
- People abuse your tools without reading the documentation,
- People do install a newer libtool.m4 with an older ltmain.sh or vice
versa,
- People do update their intl/ directory or po/ directory manually
without updating the m4/gettext.m4 macro,
- etc.
When things don't work then, they say "gettext is hard to use" and sometimes
write to bug-gnu-gettext.
The same can happen with gnulib, because we offer an open collection of files,
with no releases, and not everyone uses gnulib-tool yet. When things then
don't work as expected - even if in gnulib everything is correct - people
would still think "gnulib is hard to use".
It is to avoid problems in this area that I want to be careful with renamings.
The particular problem that can happen if (1) and (2) is done together is
that someone looks at modules/stdbool, sees that he needs to use a new
macro, does that - and gets autoconf errors because he missed to update his
macro. He would think "gnulib is hard to use".
Bruno
_______________________________________________
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
