Eric Blake writes:
> > You had the earlier proposal of making automake be smart enough to install
> > the latest upstream version of docs, rather than the version that was
> > current when automake was released (but most likely out of date at the
> > time that automake is used on a package). If that is done, then I could
> > see making fdl.texi a responsibility of automake. But for now, I find it
> > much more convenient to use gnulib, which is already an up-to-date
> > repository, as the source of COPYING, texinfo.tex, etc., rather than
> > relying on the out-of-date versions that automake would install.
"much more convenient", certainly, because automake doesn't yet have
the repository of up-to-date infrastructure files. But is that a good
reason?
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.
2) Similarly for texinfo.tex: If it gets added to a gnulib module,
we get another conflict between "automake -a" and "gnulib-tool --update".
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,
- 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".
Bruno
