On 1/4/06, Bruce Dubbs <[EMAIL PROTECTED]> wrote: > 1. Ignore the issues. > 2. Add i18n / CLFS issues to each package as they come up. > 3. Have a section or appendix in the book to address the issues and > link each package to the appropriate part. This is the approach > that has been taken for i18n so far. > 4. Link each section of the book, as required, to an external wiki/web > page to address i18n or non-x86 issues.
Not an editor here, but I like 4. For non-x86, this would require an editor making a change to have access for testing on multiple arches. I don't see how that's generally possible. Also, different dependencies/commands for different arches would make the book unwieldy. It makes sense that if, for example, Jim Gifford finds that on MIPS package xyz needs some change, it should be available as an external resource. But to require that an editor updating a package should have to test on MIPS or get Jim to test on MIPS is insane. Leave the MIPS/multi-lib/etc. hacks in a separate resource where it can be edited by those most knowledgeable about the issues of that arch. As for i18n, I'd like to see as much of this as possible go into the BLFS book since that's the way LFS is going with UTF-8. Certainly there will be cases where some advanced configuration issues come up that might be better not to be on the main page of the book. This makes the external wiki or whatever sound even better to me. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
