Alexander E. Patrakov wrote: > I don't use anything except Debian now (i.e., have no LFS) and don't follow > the upstream development (was too busy with my PhD, and now I am looking for > a new job). So, I can't give any up-to-date advice. The last information that > I posess is: > Alexander, thank you very much for your detailed response, it really is appreciated. I am so hopelessly in the dark with this issue because I speak and read only one language, and am only familiar with languages written right to left, with latin based characters (is Romantic languages the proper term?). > 1) There must be consistency!!! And this requirement will never change. I.e., > it shouldn't happen that some packages install UTF-8 manual pages and some > install 8-bit manual pages. While consistency is not normally a problem, it > is a huge problem for the huge BLFS book to change from one consistent scheme > to another. For this reason alone, I don't recommend any changes. > Even as a BLFS dev, I personally don't care about the amount of work involved for this. BLFS is just big. Given the amount of packages vs. the number of active developers/contributors, BLFS is instantly out of date at release. There is just not a whole lot that we can do about that ATM. With a little poking and prodding of the editors, it will get done. Secondly, BLFS should _not_ be a consideration when it comes to determining the 'right' thing to do in LFS. > 2) Man-DB can be built with gdbm which is much more lightweight than BDB (and > that is how it is built in Debian). > > 3) Man-1.6f still uses the obsolete catgets() system for message translation > and thus outputs garbage instead of error messages in UTF-8 locales. So, if > LFS goes to Man, it should completely disable translations of man error > messages by passing "+lang none". > > 4) Groff CVS can read UTF-8 manual pages (at least for Ruissian, no idea > about > CJK) and produce UTF-8 output if started with "-Tutf8 -K UTF-8", but in > traditional 8-bit locales one needs the output in the user's 8-bit charset, > not UTF-8. > > >> In skimming through the groff archives 200801-current, >> http://lists.gnu.org/archive/html/groff/ , it doesn't look like anything >> has happened in CVS for CJK support. ManDB with the debian groff patch >> is the only solution for Japanese. Chinese and Korean are still in the >> dark even with that. I guess my real question is what exactly do we >> loose by dropping back to Man with current groff-1.19.2. I do realize >> that what we have now works well in most cases. >> > > If you really want to stick with the current stable versions of Man and Groff > and have the possibility to choose or not choose UTF-8 locales, then please > implement the method from the "5. WHEN EVERYTHING WORKS BY DEFAULT" section, > i.e., remove _all_ translated manual pages from all packages in LFS and BLFS > and/or patch Man not to look for them at all. This is the only "right" thing > to do now, because such support is based on either obsolete standards > (ISO-8859-1) or, even worse, hacks. This will also serve better for the > readers, as in many packages the translations of manual pages are horribly > outdated. > OK. I'll give both arguments...
IIUC, what we have now in LFS SVN is the best that we can do with what we have to work with. It is what Debian is doing, so we do have a reliable group of developers to follow. It will change in the future, but who knows when that will see the light of day. What about our own roll-up of a stable snapshot of groff CVS (perhaps we can look at RedHat's example), and force UTF-8 locales? Not that it really gains us much now. Despite Debian's working (at least fairly well) solution, ISTM that the future is heading in the opposite direction. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
