Re: inetutils ChangeLog doc/Makefile.am doc/inetuti...
After the patch I installed to inetutils [1], I think actually the only problem is that the gnulib 'fdl' module is a moving target. That doesn't really work, as Karl explained, since the main manual needs to be updated manually whenever there is a FDL version update in gnulib. Right. So in gnulib, I propose we deprecated 'fdl' and ask maintainers to depend directly on 'fdl-1.3' or whatever version they need. Thoughts? I agree. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug-inetutils] Re: inetutils ChangeLog doc/Makefile.am doc/inetuti...
doc/fdl.texi is removed below If I'm understanding correctly, removing fdl.texi seems wrong to me. I'm supposing it's created dynamically from a copy in gnulib or somewhere now? But the license can't be updated merely by changing that file. The @copying block has to be updated also. In fact, the @copying block now says 1.2, but (I'm guessing) fdl.texi v1.3 is what gets pulled in. I think the right outcome is: 1) change 1.2 to 1.3 in @copying in inetutils.texi. 2) keep a copy of fdl[-1.3].texi in the repo. 3) in the event that the fdl is updated, both things need to be updated. I don't know of any plausible way to automate it, and updates are so infrequent, it doesn't seem worth the effort. You raise good points and thank you for catching them, I am not sure what we should do. coreutils for example doesn't include fdl.texi, and coreutils is generally our guideline when it comes to these things. Jim and co, what do you think? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: inetutils ChangeLog doc/Makefile.am doc/inetuti...
Alfred M. Szmidt a...@gnu.org writes: doc/fdl.texi is removed below If I'm understanding correctly, removing fdl.texi seems wrong to me. I'm supposing it's created dynamically from a copy in gnulib or somewhere now? But the license can't be updated merely by changing that file. The @copying block has to be updated also. In fact, the @copying block now says 1.2, but (I'm guessing) fdl.texi v1.3 is what gets pulled in. I think the right outcome is: 1) change 1.2 to 1.3 in @copying in inetutils.texi. 2) keep a copy of fdl[-1.3].texi in the repo. 3) in the event that the fdl is updated, both things need to be updated. I don't know of any plausible way to automate it, and updates are so infrequent, it doesn't seem worth the effort. You raise good points and thank you for catching them, I am not sure what we should do. coreutils for example doesn't include fdl.texi, and coreutils is generally our guideline when it comes to these things. Jim and co, what do you think? After the patch I installed to inetutils [1], I think actually the only problem is that the gnulib 'fdl' module is a moving target. That doesn't really work, as Karl explained, since the main manual needs to be updated manually whenever there is a FDL version update in gnulib. So in gnulib, I propose we deprecated 'fdl' and ask maintainers to depend directly on 'fdl-1.3' or whatever version they need. Thoughts? I cc yet another list, bug-gnulib, to get this archived for the gnulib context as well, in case we end up modifying gnulib. Note that gnulib does not contain a 'gpl' or 'lgpl' module, only 'gpl-2.0', 'gpl-3.0', and 'lgpl-2.1'. (Although no lgpl-3.0..) So it seems the 'fdl' module is sub-optimal. /Simon [1] http://lists.gnu.org/archive/html/commit-inetutils/2009-05/msg1.html ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: inetutils ChangeLog doc/Makefile.am doc/inetuti...
After the patch I installed to inetutils [1], Which is good, thanks. So in gnulib, I propose we deprecated 'fdl' and ask maintainers to depend directly on 'fdl-1.3' or whatever version they need. Thoughts? Makes sense to me. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
