Jim Gifford wrote:
Recently LFS has added support for UTF-8. We at CLFS are also looking
to include support for UTF-8, but not the same way that LFS has it
done. If you noticed a few package changes were added to incorporate
these changes, Berkeley DB and Man-DB. The developers of CLFS don't
feel all of these package changes are necessary and are looking for
alternative ways to implement UTF-8. So any feedback the CLFS
community has on this topic will be welcomed.
There is one more option: revert the UTF-8 changes in LFS trunk and
(although that's a lot of work) the LiveCD.
1) huge patches (with bad bug history, but UTF-8 support is required by LSB)
2) ncursesw (wastes memory in non-UTF-8 case, requires watching upstream
for fixes in UTF-8 case)
3) man-db (db is a space-time hog, alternative solutions are welcome)
4) bootscripts
I came to the conclusion that they are a useless toy right now. Some
history is below.
When I started raising BLFS UTF-8 related issues, the agreement was that
I should not do that until UTF-8 is officially in LFS. But that didn't
help because BLFS is understaffed: nano is still not upgraded to 1.3.9,
the note on MP3 players is still not in the book, and it is still
impossible to create a Windows-readable CD with non-ASCII filenames in
UTF-8 locale.
With such low speed (determined by purely objective factors, so please
don't take my statement as an attack), it is quite likely that when the
LFS release actually happens, BLFS will be nowhere near ready. That is
actually worse that having no UTF-8 support and clearly stating that.
OTOH, if anybody wants this and will help, I will be happy to fork both
books simultaneously and drop non-verified packages from my copy of BLFS.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
