Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson writes: >> So I don't see where the conflict is. > > We do not yet have a conflict. But we nearly have it: > > 1) If fdl.texi gets distributed by automake as well, we get a conflict: > "automake -a" and "gnulib-tool --update" would install different > copies of the file. Quite confusing for the user to have the same > file installed by different tools in different versions.
I'd agree with your entire argument IF automake -a actually did install fdl.texi, but my testing suggest that it doesn't. It doesn't even install fdl.texi when I do 'make install' for automake. So automake doesn't appear to be a more canonical distribution point for fdl.texi than any other package that use fdl.texi internally. Gnulib seems like a good canonical distribution point. > 2) Similarly for texinfo.tex: If it gets added to a gnulib module, > we get another conflict between "automake -a" and "gnulib-tool --update". Agreed. > 3) Integration issues: The set of tools need to fit nicely together, if > people shall get a feeling of a "GNU Build System". People don't get > this feeling if > - texinfo.tex is installed in build-aux/, whereas fdl.texi is > installed in $docbase, Not sure I agree here -- texinfo.tex seems more appropriate in build-aux/ than in doc/ to me. > - the automake doc says that automake distributes "Programs automake > might require" but doesn't distribute fdl.texi, whereas they > have to look in the "portability library" for where to get the > doc license which is unrelated to "portability" and unrelated to > "library". Automake doesn't require nor use fdl.texi, or does it? Getting fdl.texi from gnulib is a convenience, and if automake doesn't already provide it, having gnulib do it seems unproblematic. /Simon
