Re: [bug-hello] gnulib and hello

[Alexandre Duret-Lutz]

>>> "Karl" == Karl Berry <address@hidden> writes:

 Karl> The vision of gnulib is to provide files for sharing at the source
 Karl> level, by maintainers who want the latest and (hopefully) best files.
 Karl> Overall I think this is a good thing for Hello to recommend.

OK, you simply do not target the same people as I though GNU
Hello should target.  Undoubtedly there are different levels of
Hello World, and I understand GNU Hello can only be one.

I met Akim two days ago, and when I mentioned GNU Hello being
revived his first answer was: "it would be nice to show an
example of Swig."  (That's because he had a hard time finding a
correct setup for his own package using Swig lately.)  Only then
did I explain him that the plan was instead to restrict the
functionalities.  Anyway the point is that experienced people
would like to see advanced examples, and newbies will certainly
want something they can toy with using their installed tools and
that is not encumbered by bleeding edge stuff or complex tricks
that make the maintenance easier once well understood.

I guess there is no way to please anybody.

 Karl> That's the theoretical argument.  The practical argument
 Karl> is that there is no other way to get the nontrivial
 Karl> functionality (close_stdout, error, etc.) that Jim
 Karl> mentioned.

I think I mentioned it already.  This is how I always did so
far, and probably how you did before gnulib: get a copy of the
files you need, stick them into your CVS, and update them
periodically.  This does not need to be done during bootstrap,
it can be done by a rule in the Makefile.

 Karl> Next point: because gnulib is intended for incorporation into source
 Karl> distributions, it is not appropriate for it to be installed in the usual
 Karl> way.  (Thus I think Debian was quite wrong to make a package for it.)
 Karl> The whole point is to get the *latest* files, and that means using the
 Karl> files from gnulib cvs.

Why the *latest* files?  Why would you use the CVS version of
these files, and not also the CVS versions of Autoconf and
Automake?  I can't see the difference.  There are many bugs
fixed on the stable branch of CVS Automake that impact
everybody's package and yet people do not care and still use
whatever they have.  The same can hold for gnulib, hence the
Debian package (the existence of which I'm glad to learn).

 Karl> And therefore I do not think it makes sense, even in theory, for
 Karl> autoreconf to ever call gnulib-tool.  Autoreconf *is* intended to be
 Karl> installed.  Mixing installed programs and cvs programs ... no thanks.

I'm afraid that sounds like an argument to install gnulib too me :)

 Karl> What autoreconf can do, as I mentioned in my other message, is avoid
 Karl> overwriting newer files with older ones.  (This is nontrivial in itself,
 Karl> since it has to find the serial numbers or timestamps inside the file to
 Karl> compare.)

Simply do not use -f and you should be OK.  What are the files
that are installed by both tools anyway?  And why?  My feeling
is that we should arrange that no two tools install the same
file.

 Karl> If that were done, then I can imagine autoreconf including a snapshot of
 Karl> various gnulib modules, or maybe even gnulib in toto, at its releases.
 Karl> Then maintainers who want to stay a little behind the bleeding edge can
 Karl> at least get updates with new autoconf releases.  And those who use
 Karl> gnulib will not be hurt by it, and could also use autoreconf for all
 Karl> that other things it does.

That sounds good to me (although I don't understand what "in toto" means).
-- 
Alexandre Duret-Lutz