On Thu, 5 Jan 2006, Bruce Dubbs wrote:
The way I look at it, we have four possibilities:
1. Ignore the issues.
I hope not, even though I sometimes hate change :)
2. Add i18n / CLFS issues to each package as they come up.
I can't speak for i18n, but CLFS in itself doesn't have many issues -
x86_64{,-64} (multilib and 'pure64' ), ppc, and the other arches _do_
have issues on certain packages, but many of these issues are
arch-specific. (actually, for a while CLFS had issues with strace, but
LFS-svn has the same issues)
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.
I'm not quite sure how this will work for clfs (and I've paid little
attention to i18n beyond skimming the postings).
4. Link each section of the book, as required, to an external wiki/web
page to address i18n or non-x86 issues.
Wikis and lfs don't seem to fit well together, from past experience.
The bigger difficulty is trying to keep versions in sync - wikis get
updated when joe builder decides to build foo on his new system and
notices that the instructions don't match the current version.
But even if you put the arch differences in the book, it's a matter of
finding somebody able to try out a new package on the various platforms
with the appropriate version of the book (another problem - after an
LFS release there is usually a delay in bringing out a matching blfs
book, and then you guys revert to tracking lfs-svn - for CLFS, releases
are unlikely to match the LFS release dates and (certainly at the
moment) "minor" packages like e.g. glibc are using different versions ;)
I shall watch this thread with interest.
Ken
--
das eine Mal als Trag?die, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
