[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-hello] gnulib and hello
Re: [bug-hello] gnulib and hello
Sat, 11 Dec 2004 01:09:00 +0100
Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux)
>>> "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
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
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
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).